Methods and systems for creating a semantic object

ABSTRACT

Among other disclosure, a knowledge network and semcards enabling intelligent matching of offers and requests, involving all types of information and knowledge, including information such as classified ads, data about products and services, or knowledge, expertise, ideas, suggestions, opinions, and other forms of tacit knowledge is described.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims priority under 35 USC § 119 toProvisional Patent 60/427,550 filed on Nov. 20, 2002, titled SemanticNetwork Platform, Framework and Application, incorporated herein for allpurposes.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to computer software and networkapplications. More specifically, it relates to software for implementingknowledge management systems and knowledge representation.

2. Discussion of Related Art

Knowledge workers, teams and organizations routinely work with a largeand complex array of information. This includes e-mail messages, instantmessages, chats, discussion postings, calendars, contact and to-dolists, documents, photos, maps, and database records. This informationalso includes tacit knowledge and expertise that resides only inpeople's heads. The average knowledge worker interacts with severaldozen information types, hundreds of Web sites, and dozens of differentapplications. Existing information systems are focused mainly on data,rather than on relationships between data. There is a growing need toenable applications and users to see how various types of informationare related across different information systems and locations. However,there is no tool for connecting, managing and sharing this informationin a unified way.

The growth of the Internet, as well as the increasing amount ofinformation it contains, are leading to serious problems for manycomputer users. In particular, they are leading to a problem referred toas “information overload” in which parties are overwhelmed by moreinformation than they can effectively process, navigate, search, track,respond to, utilize, cope with, or manage given limited time andresources.

A related problem is “information complexity” in which, due to the sheervolume of information choices on the Internet, and its disassociatednature, is making it overly difficult to locate particular desiredinformation when it is needed. Another related problem is“dis-integration” that arises due to incompatible or nonstandardinformation and services, which leads to software and serviceincompatibilities, as well as obstacles to processing and managinginformation effectively. Another problem is “spam” that arises whenInternet participants receive unsolicited, unwanted, or irrelevantinformation from other parties on the Internet. An additional problemthat is related to spam is “lack of targeting” which arises becauseinformation providers such as publishers, advertisers, and marketers areunable to effectively distribute their information to appropriate,interested parties, due to lack of information about the interests andpolicies of those parties.

Another related problem that is also related to spam is called “lack ofpersonalization” which arises when parties on the Internet are unable toeffectively subscribe to, filter or control the information they getfrom others. Another problem is “lack of privacy control” which resultsbecause Internet participants are unable to effectively control whatinformation about themselves is shared with or by other parties on theInternet. Yet another drawback is “information deficit” that resultswhen parties are unable to find, or do not receive, the information theyneed or are relevant to, even though it is available somewhere on theInternet or even on their own computers.

These problems, and related problems, are becoming serious obstacles toknowledge work, commerce, collaboration, publishing, marketing,advertising, search, communications and communities. In particular theseproblems are reducing the productivity of Internet participants. Partiesmust spend increasing amounts of time and resources searching forinformation they seek, trying to ensure that they receive informationthey want from others, trying to block or delete unwanted informationreceived from others, responding to information they receive fromothers, managing and organizing information they want, tracking changesto information of interest to them, trying to distribute relevantinformation to others appropriately and trying not to mistakenlydistribute unwanted or irrelevant information to others. With theexpanding and pervasive use of the Internet and its increasingly centralrole in relationships, interactions and transactions of all kinds, thoseentities that provide content and/or Internet software tools andservices are searching for and implementing ways to solve the aboveproblems. However, attempts to solve these problems face numerousobstacles. Presently the Internet is comprised of many separateinfrastructures and software tools that are used for different modes ofcommunication. For example, e-mail communication takes place via e-mailservers and client software applications that communicate viaspecialized e-mail messaging protocols, yet Web searching for exampletakes place using search engines and databases that are accessed via Webbrowser software and Web transaction protocols. Thus, even if one wereto solve the problem of information overload for e-mail it would notnecessarily solve this same problem for Web searching.

A principal problem stems from present systems' inability to store,route and use meta-data about the data resources that they manipulate.It is therefore a goal of the present invention to provide acomprehensive solution to these limitations, in the areas of informationoverload, search, sharing, collaboration, communication, transactions,knowledge management, information distribution, and automated and manualmanipulation of computer-stored data and resources, allowing informationto be connected in meaningful ways.

Using traditional search systems, parties seeking something enterqueries that are tested against databases of information that areprovided by one or more parties with things to offer. If matches arefound, the seekers are notified with links to the appropriate provider.One problem with such systems, however, is that they do not work inreverse; there is no way for providers to locate seekers who want whatthey offer. Instead, providers must wait passively to be found byseekers. Seekers on the other hand, must do all the work. Anotherproblem is that it offers only search by keyword; there are nomechanisms that support higher-level organization of the information.

Providers who want to be found may resort to marketing in order to reachseekers. For example, many search engines provide an option to buykeyword advertising, enabling providers to market what they offer toseekers who enter relevant queries. Although they do this, they do notenable providers to search for seekers who want what they offer, nor dothey help them locate seekers who are not presently searching but arestill interested. Thus providers must use external marketing channelssuch as direct email, banner advertising, paper-based direct mail andother forms of advertising to locate interested seekers. Theseinefficiencies result in increased transaction costs for seekers and forproviders.

The present invention provides a single universal underlyinginfrastructure for managing information overload, distributing, locatingand filtering information between information providers and recipientsthat works equally well across all types of Internet relationships,interactions and transactions. This single solution can be used to routeand filter e-mail and instant messages, search the Internet, sharefiles, publish and subscribe to information, market and advertise,coordinate and collaborate with others, personalize services, engage inonline communities, and improve the efficiency of on-line commercebetween buyers, sellers and intermediaries.

SUMMARY OF THE INVENTION

In one aspect of the invention, the knowledge network and semcardsenables intelligent matching of offers and requests, involving all typesof information and knowledge, including information such as classifiedads, data about products and services, or knowledge, expertise, ideas,suggestions, opinions, and other forms of tacit knowledge. The presentinvention is capable of intelligent matching of offers and requests,involving all types of knowledge: Information, ideas, suggestions,opinions, products, services, jobs, events, people, skills, etc, usingsemcards and semcard-like structures, creating a bi-directionalmarketplace on the Internet, desktop or intranet. The invention enablesparties to search and do marketing in the same way, in the sameenvironment.

A semcard can be designated as an offer or a request and for variouspurposes including advertising, offering items, or finding items. Withdirect targeting a semcard is sent to specific recipients with which thesemcard's creator has an existing relationship. With indirect targeting,on the other hand, a semcard is sent to recipients who satisfy variouscriteria. When the semcard has been specified to the user's satisfactionit can be test-posted. Using semantic routing, semcards that representoffers, requests, and queries, can be routed semantically between nodeson the network. The routing profile describes salient features of thesemcard, as deemed necessary for supporting efficient routing ofsemcards. Collections of semcards can also be matched or compared in aknowledge network. Users can also create new semcard templates or extendthe ontology, and share these extensions with other users in thenetwork.

In another aspect of the invention, the semcard management applicationprovides statistics on phenomena such as supply and demand trends forparticular types of offers, requests and semcards, number of users witha particular interest profiles, number of potential matches forparticular advertisements, and distribution of the user population alongmultiple dimensions.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be better understood by reference to the followingdescription taken in conjunction with the accompanying drawings inwhich:

FIG. 1 is a block diagram of the basic semcard structure and an exampleof a semcard containing sample meta-data.

FIG. 2 is a block diagram showing relationships among a semcard, asample referenced semcard, computer-readable data pointed to by thesemcards, and an ontology.

FIG. 3 is block diagram showing another example of a primary semcardreferencing a second semcard both of which reference the same ontology.

FIG. 4 is a block diagram showing the various lifecycle stages of asemcard.

FIG. 5 is a block diagram showing numerous semcards and links comprisinga knowledge network.

FIG. 6 is a block diagram showing two semcards connected by a linksemcard defining a relationship between the two semcards.

FIG. 7 is a flowchart illustrating a method of the internal process forcreating a semcard.

FIG. 8. is a sample screenshot from the user interface of semcardmanagement application showing various panels.

FIG. 9 is a schematic diagram illustrating an initial state of asimplified example of the notion of contexts in the semcard managementapplication.

FIG. 10 is a schematic diagram illustrating a context being populatedwith relevant semcards.

FIG. 11 is a schematic diagram showing the appearance of pointers tosemcards upon selection of a context.

FIG. 12 is a schematic diagram showing the creation of a sub-context toa super-context.

FIG. 13 is a schematic diagram showing the appearance of pointers tosemcards upon selection of a sub-context.

FIG. 14 is a schematic diagram showing the appearance of all pointers tosemcards originating from a super-context and its sub-context uponselection of the super-context.

FIG. 15 is a schematic diagram showing the association of a rulecollection semcard with a particular context.

FIG. 16. is a block diagram showing a selected entry point, a resultspanel, and a viewer panel with tabs indicating various displays.

FIG. 17 is a block diagram showing contexts and a results panelcontaining various sorted semantic dimensions and values.

FIG. 18 is a block diagram showing a pool of semcards, their semanticdimensions and values, and their relationship to an ontology.

FIG. 19. is a block diagram showing a filter panel container with onefilter panel.

FIG. 20. is a block diagram showing a new filter panel appearing as aresult of user selection of a filter panel feature.

FIG. 21. is a block diagram showing a third filter panel appearing as aresult of user selection of a second filter panel feature.

FIG. 22 is a block diagram showing the results of a user selection of athird filter panel feature.

FIG. 23 is a sample screenshot from the user interface of the semcardmanagement application showing a “stacked” layout of filter panels.

FIG. 24 is a block diagram showing the “stacked” layout of threeconsecutive states of a filter container upon the application of filterson selected features.

FIG. 25 is a schematic diagram showing the How tab on the Relationshipsemcard, allowing permissions and default policies to be set.

FIG. 26 is a schematic diagram of a knowledge network consisting ofnumerous semcard management application peers with relationships.

FIG. 27 is a schematic diagram extending FIG. 26, showing more complexrelationships between peers.

FIG. 28 is a schematic diagram showing routing of semcards using serversin a peer-to-peer network.

FIG. 29 is a schematic diagram showing routing of semcards using serversin a network of peers and servers.

FIG. 30 is a schematic diagram of matching mechanisms used on semcards.

FIG. 31 is a schematic diagram showing details of matching two semcards.

DETAILED DESCRIPTION

Reference will now be made in detail to a preferred embodiment of theinvention. An example of the preferred embodiment is illustrated in theaccompanying drawings. While the invention will be described inconjunction with a preferred embodiment, it will be understood that itis not intended to limit the invention to one preferred embodiment. Tothe contrary, it is intended to cover alternatives, modifications, andequivalents as may be included within the spirit and scope of theinvention as defined by the appended claims.

The present invention presents a comprehensive system for augmentingcomputer-mediated collaboration and communication of knowledge andinformation, using the concept of semcards, that can be interconnectedvia a particular type of semcard that functions as a semantic link, toform distributed knowledge networks.

A semcard is a semantic software object that contains slots withsemantic tags, and content, all of which can be representedsemantically, optionally using an ontology, and rules embodying optionalrules regarding automation, goals, display, access permissions and otherpolicies, sharing, and other operations of the semcard and its targetreferent. The target referent is what the semcard is about: it is anentity or concept that the semcard represents or describes and holdsmetadata about. It can be a physical entity such as a living person, asoftware entity such as a data record or word processing document, or anintangible entity such as an idea or thought or feeling. Any type ofdigital object or information can be attached to a semcard, e.g. adigital certificate, a link to a web page or a product or service offer,an SKU, a data record in a database, or knowledge item, software, or afile or media object, media streams, a link to a remote Web service,etc. Semcards can also be used themselves to represent the relationshipbetween other semcards, for example, that the person is the author ofthe idea.

A semcard can be thought of as a form with fields or slots, and has twoincarnations, template and instance, which correspond roughly to theobject-oriented programming concepts of object template and objectinstance.

As shown in further detail in FIGS. 1 and 2, each semcard has numeroussemantic dimensions, also referred to as meta-tags in the semcardtemplate. For example, for a semcard representing a material object, asemantic dimension (meta-tag) can be “color”, which contains aparticular value (meta-data), and restrictions on what kind that valuemay be. (Semcards are also used to represent the semcard templatesthemselves.) To fill out a semcard, an instance is made of a semcard'stemplate, and selected slots of the instance are filled with values.Each semcard instance, its semantic dimensions, and their values foreach semcard, can be stored on a computer readable medium as an XML(eXtensible Markup Language) object, using the RDF (Resource DescriptionFramework) format, any binary storage format, or other chosen format.Semcard templates can be created by designers, who hand-pick themeta-tags that define the semcard's referent target. Semcards can alsobe created dynamically and automatically through automated selection andorganization of meta-tags from a pool of metatags; the selection ofmeta-tags and their organization in the semcard being driven byheuristic rules, e.g. by the meta-tags' popularity with a group ofsemcard users and authors.

Referring to FIG. 1, a semcard 1-1 contains rows, called slots, 1-2 forstoring metatag-metadata pairs, tags on the left side 1-3, metadata onthe right-hand side 1-4. A semcard 1-2 with example tags 1-6, 1-8, 1-10,1-12, 1-14, 1-16 and example values for each tag 1-7, 1-9, 1-11, 1-13,1-15. Slot 1-17 would hold a reference to a link semcard, as explainedfurther below and in FIG. 6. In a preferred embodiment of the presentinvention, semcards are defined in XML that can be easily transformedto/from other data formats, including other XML formats, HTML, RSS, RDF,SHOE, DAML+OIL and OWL, as well as other application specific dataformats. For the purposes of the present invention, the size andcomplexity of a semcard can vary. A collection of semcards linkedtogether is referred to as a knowledge network. In a preferredembodiment, people can access and manipulate individual semcards, andknowledge networks, via desktop tools, as well as with standard Webbrowsers.

Referring to FIG. 2, a semcard 2-1 contains data 2-2 which references2-3 to an external entity 2-4, stored on a computer-readable medium 2-5(The link 2-3 to the external entity 2-4 is itself a semcard, as shownin FIG. 6.) The semcard's 2-1 tags 2-6 are defined 2-11 in an externalontology 2-7, which has standard nodes 2-8 and relationships betweenthem 2-9. The semcard 2-1 contains data 2-12 which references a displayspecification 2-14, said display specification containing data 2-15referencing 2-16 an application 2-17, stored in a computer-readablemedium 2-18, said application being used to view and manipulate theentity 2-4 referenced by the semcard 2-1. The display specification 2-14containing tags 2-19 which are also defined 2-20 in ontology 2-7. Thisontology can be the same or a different ontology that defines the tagsfor the semcard 2-1. (The link 2-16 to the external display instructions2-17 is itself a semcard, as illustrated in FIG. 6.)

Data in semcards can be defined using an ontology. An example is a dataelement like ‘Dalmatian’ as the data value for the tag ‘breed’.Referring to FIG. 3, a semcard 3-1 contains a reference 3-13 to adisplay specification 3-14, and data elements which reference 3-8 nodesin an ontology 3-7, stored in a computer-readable medium 3-5, saidontology 3-7 containing nodes and links. Said display specification 3-14containing data which also reference 3-9 nodes in an ontology 3-4. Thisway both the tags of a semcard and its data can be defined in anontology, the benefits of which are an ability to compare two or moresemcards created by separate users at different times.

Although the amount of metadata in a single semcard can be very small orextremely large, a semcard is intended to be of a convenient size from acognitive standpoint, so as not to overload its user with too muchinformation. For example, a semcard describing an automobile would havethe typical “common sense” data about its color, type, seating, enginepower, etc.; if more information was desired to be represented about thecar's engine, a separate semcard could be created for this purpose, andlinked to from the automobile semcard. This way the relationship betweensingle semcards and collections of semcards—or knowledge networks—iskept at a cognitively manageable ratio.

In a preferred embodiment, part of the metadata of a semcard representsits lifecycle stages. There are four lifecycle stages of a semcard: (a)Draft, (b) active, (c) inactive, (d) deleted. FIG. 4 is a block diagramshowing the lifecycle stages 4-1, 4-2, 4-3, 4-4 of a semcard. A semcardstarts out in draft stage 4-1, and transitions from this sequentiallythrough stages 4-5, 4-7, 4-9 based on events 4-6, 4-8, 4-10 which areinitiated by the user or automatically initiated through rules codifiedin the semcard's policies or automation instructions or elsewhere, or byother means. The transition from draft 4-1 to active 4-2 happens throughan activation event 4-6, which is initiated by the user, by automaticrules, or by other means. The transition from active 4-2 to inactive 4-3happens through de-activation event 4-8, which is initiated by thesemcard's maximum lifetime, by user-driven events, by automatic rules,or by other means. The transition from inactive 4-3 to deleted 4-4happen through a deletion event 4-10, which is initiated by a user, bythe Semcard Manager's determination that the semcard is no longerneeded, by other automatic rules, or by other means.

Referring to FIG. 5, a semcard 5-1 unifies information about a person,using pre-defined slots with pointers 5-14 to relevant information,including their names 5-3, date of birth 5-5, contact information 5-7,addresses 5-9, friends 5-11, and authored document 5-13. Semcards 5-2,5-4, 5-6, 5-8, 5-10, 5-12 relate each relevant semcard to the personsemcard 5-1. In a preferred embodiment, slots on semcards can be definedto be required slots, i.e. belong to the object, and thus traveling withit when shared, published, copied, etc. In this example, the slots for aperson's name and address are defined as required slots, and thus bydefault belong to the person semcard 5-1, whereas the ‘Friend-Of’ linkis optional. When a semcard is shared, its optional slots require theowner of the object to explicitly designate them as shared; the requiredslots are shared by default when their parent object is shared. In theexample of FIG. 5, if semcard 5-1 were to be shared, the semcards 5-10and 5-11 would not be shared, by default—they would have to bespecifically designated as shared.

Semcards are intended to represent a variety of common types of things,and templates for a variety of common things are provided by the semcardmanagement application, including relationships, interactions andtransactions including communications such as e-mail, instant messages,alerts, bids, announcements, questions, answers, invoices, receipts,proposals, search queries, invitations for participation inrelationships and events and activities of various types, content,files, advertisements, brochures, catalogs, publications, subscriptions,opportunities, coupons, etc. In addition to these specific types of dataand knowledge, semcards can also represent ideas, concepts, and otherforms of tacit or intangible knowledge.

The following is a partial list of what semcards can be used to exchangeand share: e-mail messages, instant messages, discussion threads andpostings, chat messages, XML messages, directory listings, files,advertising and marketing, invitations, tasks, orders, invoices,receipts, information about auctions and bids, charges and payments,software and software updates, multimedia content, referrals for things,polls, surveys, reviews and opinions, data records, data streams,questions and answers, Web sites and Web pages, alerts andnotifications, pop-up alerts, on-screen and audio notifications,information about events, information about opportunities, informationabout products and services, information about people, organizations andgroups, information about topics, classified ads, publications andsubscriptions, commands and reports, information about relationships,ontologies and ontology branches. Semcards can also be used to buy andsell things and other transactional tasks, to trade things, trackinterests and watch for events, filter information, publish information,subscribe to information, distribute information or digital products andservices to targeted recipients, distribute information to fuzzy sets ofrecipients, interact anonymously, sell pay-per-view links toinformation, buy and sell semcards, transfer funds between parties basedon transactions following from matchings between their semcards,brokering relationships and interactions between parties, send orreceive semcards to/from parties who are indirectly related to a partyby varying degrees of social distance (sequences of indirectrelationships of varying number that connect the parties).

Semcards can be generated either manually by a user or automatically bythe system. For example, user A finds a useful URL and creates a semcardfor it. He includes his comments and description of the web page. Thesemcard gets metadata from the URL's web site automatically. User Alinks the semcard to projects and documents for the team. user A storesthe semcard in his semcard space. By doing so user A can be notified ofchanges to the site. He gives a copy of the semcard to user B who savesit all in his semcard space and adds his own data and comments, andattaches a file to it. The semcard that user A has is automaticallyupdated to reflect user B's changes. It is synchronized with user B'scopy and now gives user A access to user B's comments and the file thatuser B attached, which can stay on user B's semcard space on his peer orcan be stored at another location.

Semcards can also be created fully automatically, for example, by datamining various resources on the Internet after those resources have beencreated. This can happen in advance of the semcards being needed oron-demand such as in response to queries.

Semcards can be created simultaneously with the creation of the contentthey will represent by including a semcard creation procedure withinapplications such that upon certain events they trigger semcardcreation. Alternatively, semcards can be created via a semcard creationdaemon that watches file directories and applications for various eventsand then triggers semcard creation. Alternatively it can be donemanually by the user from a menu embedded in applications. In all thesescenarios various events may be set to trigger semcard creation andmodifications:

-   -   saving a document or data item    -   creating a document or data item    -   opening/viewing a document or data item    -   modifying a document or data item    -   transmitting a document or data item    -   receiving a document or data item    -   deleting a document or data item    -   integrating documents or data items with existing file    -   servers,

Databases or Search Engines

Semcards embody metadata about their target reference as well as theirown structure; they are self-describing and are structured in atype-attribute-value form, where type is the unique type of the datathey represent, attribute is one or more metatags, and value is one ormore metadata elements. Semcards can represent anything, and theyprovide detailed information about their own structure, meaning,functionality, content, relations, policies, permissions, procedures,history, statistics, authors, users, owners, goals, and state. Semcardsare both machine-readable and human-readable; human-readable becausethey contain rules and policies relating to how they interact with andare manipulated and read by humans. A semcard's associated display rulesdictate how the semcard itself—as opposed to its target reference—shouldbe displayed to the user. These rules can specify, for example, how thesemcard should be displayed depending on the display device used, whichrender is being used, and what purpose the semcard is being viewed for.The rules can specify how, for example, meta-data (or data values) inthe semcard should be organized and what labels should be used for them,if any, as well as what aspects of the semcard appear as interactiveelements in the interface, and the results of specific interaction withthose elements.

Semcards can be transmitted over computer networks using email,traditional network routing and communications protocols, Web protocols,peer-to-peer and Web services protocols, new semantic routing protocols,etc., and can be stored on any computer-readable media. Semcards can actas search queries, by linking them to semcards designated as offers orrequests, and specifying acceptable ranges and matching rules for thevarious semantic dimensions and values of the semcard, as describedbelow.

The benefits of semcards are evident directly to their human users intheir daily work with information, augmenting current computer systemsin many ways, including but not limited to more efficient ways for usersto navigate, browse, search, share, manipulate, display, link, organize,access, and store their data. Semcards are also beneficial to currentcomputer systems by enabling more intelligent and accurate automaticmanipulation of information, including but not limited to: routing,storing, matching, searching, meta-tagging, integrating, organizing,filtering, form-filling, linking, and displaying of information. Rulesgive the owner of a semcard direct control over how semcards, and theirreferenced resources, are searched, matched, shared, duplicated, copied,on the owners' own computers as well as over a network of computers suchas the Internet. These rules can be event-driven or periodic. A rulecould for example specify that “when recipient gets this message, sendme a receipt and also forward receipt to a database; wait for a replyfrom recipient; if no reply is received, remind recipient to send areply in 3 days.” Semcards can represent streaming media, specifying themetadata bout the source from where to get the data, and what to do withit. This can be set up to be either pull or push, with policies definingconditional behavior for the standard event types associated with suchstreams (i.e. glitches, delays, overflow, loss of connection, end ofstream, etc.).

Semcards and their copies on other systems can be set to have a time tolive (TTL), such that they expire after a set period of time. Theirrules will then determine whether they should be deleted, compressed,etc., and whether the original should be notified. Semcards can also bemanually expired, independently of their TTL, by their author. For alocal semcard this is simply moving the state of the semcard from activeto inactive. For a remote semcard living elsewhere on the network thisinvolves sending a special termination signal with the particularsemcard's unique ID. The same mechanisms can be used to rescind asemcard that has already been posted.

Semcards link to other semcards using a Link semcard. Link semcards area kind of semcard that contain rich metadata about the relationshipbetween things, as represented by two connected semcards. In FIG. 6semcard 6-1 points to semcard 6-3 via semcard 6-2. In a preferredembodiment, each semcard has its own existence, history, and globalunique identifier (GUID). For example, a Document semcard can be linkedto a Person semcard using an Author-Of Link semcard. A constraint systemcan be provided such that only certain kinds of links can representrelationships between certain kinds of semcards. The constraining systemrepresents the logical way in which semcards can be linked. Morespecifically, it represents ontological knowledge about how the world iscomposed; a link between two semcards should ‘make sense’ or becomprehensible to the semcard management application and its user, thatis, the link should be consistent with the ontologies contained in thesystem.

Semcards can be used to integrate semantic representation with legacydata. For example, the system can supply a simple server that canreceive a query from a network and then translate it into one of severalpopular legacy formats (such as SQL) or custom formats (defined byadmins) and transmit it to various legacy systems, then get results andreformat them as semcards, then supply these back to the party issuingthe query. A query can be received at a network node for any whitepapers about software applications. The node can then translate thisquery into a query to a local legacy search engine. The search enginecan conduct a legacy search of local databases and return any searchresults to the node. The node can then either embed and return thoseresults within appropriate semcards on the fly (if the results are richenough) or further analyze any found documents in order to createsemcards for them to then supply to the party issuing the query.

Another approach is to data mine entire collections of digital entitiesand create semcards for the selected digital entities in advance so thatsemcards do not have to be created in real time. Searches are executedagainst the collection via standard legacy search engines and whenresults are found instead of reporting the raw results or attempting togenerate semcards at that time, the corresponding pre-existing semcardsfor those digital entities are returned to the user from a database ofsemcards.

Data mining can proceed in at least two ways: unstructured andstructured data mining. Unstructured data mining involves variousartificially intelligent agents or other software artificialintelligence applications that scour resources and determine theidentity and nature of these agents. Based on this they can then createsemcards for representing the resources. Structured data mining allows aschema to be created that guides the agents directly in creatingparticular classes of semcards. For example, an agent can be created tomake “white paper” semcards with particular policies, targeting andattributes for qualifying documents in some pre-defined, well-structuredcontent collection. The agent scours the collection and for eachqualifying document it then creates a semcard from the semcard template,automatically filling it in with information about the white papersusing the agent's built-in intelligence. Thus, the agent already knowsthat the documents in the collection are white papers having certainattributes and policies so it can more easily create semcards for themless need for advanced artificial intelligence.

The semcard management system ensures that semcards and any content theyrefer to are not separated, i.e. that the targets of semcards are notlost. A mechanism may be provided such that pointers from semcards totarget content are maintained so as to have correct addresses for thetarget content. One solution is to have a semcard representing a targetcontent, such as a document, connect to the target via a link semcard.In addition, when either semcards or the target content objects aremoved, the pointers are updated or the associated objects are movedtogether. Another solution is to wrap content objects in semcardcontainers such that the content objects do not exist outside of suchwrappers. That is, documents are stored inside of semcard objects.Another approach is to move any objects described by Semcards into aprotected storage environment such that they can only be moved under thesupervision and policies of the Semcard management application.

Another approach is to embed semcards into documents, websites,products, etc. This can be done, for example, by embedding semcard tagsin content or by attaching semcard files to content objects, by eitherincluding the files as hidden data in the documents, or as links orattachments to the documents.

Another approach is to maintain an association table of mappings betweensemcard files and target content files such that when files are moved orchanged the corresponding entries in the association table is updated.This table enables the associated semcard(s) to be found from any file,and the associated file(s) to be found from any semcard. The associationtable must be periodically updated on a regular basis or at leastupdated when changes are detected/made to semcards or any files that areindexed in the table.

To accomplish this a daemon could be provided to watch for changes andupdate the association table accordingly. There are various ways toimplement this. In one case daemons can report to some central locationwhat files they have so that other daemons can locate those files. Whenfiles are moved to locations that are not watched by daemons objects arewrapped in semcards or semcards are embedded in objects when possible.

A semcard can be divided into four main sections, (a) the What—theattributes of the offer/request and any further content payload, (b) theWho—the identity of the sender and the specification for what recipientsare to be targeted, (c) the How—any goals, rules, policies, replymethods, etc., and (c) Where—the history of this semcard, modifications,copies made, who has viewed it, links to prior versions of it, etc.These are conceptual categories of organization that may exist inisolation or exist with other features for organizing the semcards'parts; this division can, but does not need to, correspond to the waythe semcard is represented to the use.

1) The What part of a semcard describes whatever the semcard representsand/or carries, for example: a Web site or document, an opportunity, andadvertisement, data or knowledge, a file, an event, an audio recordingor electronic book, a Web service, software object, a collection ofother semcards or a non-digital product or service, or ideas and tacitknowledge.

The How part of a semcard defines the semcard's policies and procedures.

The Who part of a semcard contains an authenticated person (visible oranonymous) representing the owner of the semcard. This part alsocontains addresses for various recipient individuals, groups, or a fuzzydefinition of the qualifications for valid recipient individuals andgroups, lists of users who have modified, copied, received, or deletedthe semcard, as specified by the semcard's policies about what kind ofsuch data should be stored, and other information regarding users oragents.

The When part of a semcard contains a compact representation of thehistory of events related to the semcard. The decision about whichevents are stored with the semcards, which events are linked from to thesemcard, and which events are ignored, are determined by the rulesrelated to the semcard's history.

A method of creating a semcard is described in FIG. 7. At step 702 auser selects an empty instance of a semcard type, and fills it in withcontent values. The semcard instance is given a global unique identifier(GUID). When creating a semcard manually or a document, for example, theauthor will be provided with a selection of valid values for aparticular slot, as defined in the ontology, such as “author of”, whichwill display instances valid for the slot, such as names of particularpeople or organizations (only people and organizations can be considered“valid authors” of documents).

This would typically include all names of organizations and individuals(all potential authors) in the user's semcard space.

In the semcard system of the present invention, all data items arestored on disk continuously, that is, immediately after they are enteredby the user, so the user never has to manually “save” a semcard—this isdone automatically. Once the semcard is created, the user can commit—orpost—the semcard instance. Referring to FIG. 7, at step 704, the usercreates rules for the semcard management system, as well as rulespertaining to types of semcards, and instances of semcards. The rulescan specify, among other things:

Whether the semcard can be linked to by others

Whether various operations on, or modifications of, the semcard needmanual approval of the owner; and

How the semcard's content should be updated automatically

At step 706 the system receives a new rule, either created by the useror automatically by the system, or by some external process orthird-party, and compares them with existing rules it already stores.These rules can apply to semcards, to the semcard management applicationitself, or collections of semcards, in which case they are referred toas “global rules”. These rules may be related to access privileges, howinformation is displayed in the user interface, or any other feature ofthe system that can be controlled by rules. User-created rules, as wellas default rules provided with the semcard management application, aremanaged by an automation component with a rule engine.

At step 708 the automation component checks for conflicts with existingrules in the user's semcard system space. If no conflicts are detected,and the creator of the rule has permission to submit the rule, the ruleis stored and becomes part of the system's rule set at step 710.

Some rules may be stored with the semcard and processed by othercomponents, for example, access privileges maybe handled at a lowerlevel. Access privilege rules differ from display rules in that they areeach represented differently.

Semcards can be transformed to various formats using methods in thesemcard system. One format is intended for efficient storage in memory.Another format enables efficient transmission of the software objectsover a network. Another format enables interchange with third parties.For example, this format may be serialized XML or RDF or otherapplicable format. Semcards, and any part of their metadata, can beeasily encrypted.

Semcards, and any part of their metadata, can be digitally signed toauthenticate their origins and trustworthiness, and to control access tothem, and manipulations of them.

Many users may create links to a particular semcard external to theuser's semcard space on a network; each user may create a different setof links. The result is a network extending beyond the user's peer butresiding on each user's semcard management application which relates tothat particular semcard. If these users share their network with theworld, it is now possible to traverse a knowledge network that is thesum of all the users' networks, where the center point is the particularsemcard.

When a semcard has been posted, no matter who it is addressed to or how,it will be handled according to its own rules, and other rules in thesystem. The content of the semcard can be mined and related, andautomatically linked, to other semcards in the system (via newly createdlink semcards). Mining is typically controlled by global rules for thesemcard system. The process finds connections between semcards byexamining values and semantic dimensions in each semcard. One of thesetasks is checking for duplicate or repetitive data and concepts toreduce data storage. It can also link the new semcard with existingsemcards using inferences and other techniques.

The system also accepts plug-ins that perform as experts in determiningwhere and when there may be connections between semcards. For example, aplug-in may be an expert in corporate formations and organizations.Thus, it knows that an organization has a founder. If a semcard iscreated for an individual and that individual's name is also in anOrganization semcard, the plug-in can draw the inference that the twosemcards should be linked based on the plug-in's own rule set, whichenables it to draw the inference. The system can also make any obviouscorrections to values in the slots.

On a network, as copies of a semcard move around, a target referent ishandled according to the semcard's policies. The options availableare 1) keeping the semcard and the payload together at all times; 2)keeping them separate at all times; and 3) keeping the payload withinclose proximity so it may be cached. For this purpose, the targetreference object can be contained within the semcard, can be kept withthe semcard at all times but separately, or it can be kept remotely.

As described above, a link between two semcards is itself a semcard.However, the process for creating a semantic link is somewhat differentfrom the method of creating an object semcard. Although the user mayoften manually create a link, its content values are typically managedby the semcard system rather than explicitly by the user (although theuser can, under special circumstances, modify a link's content). Oftenthe links are created fully automatically. Links created by the systemmay be assigned a confidence value, which represents the automatedsystem's estimation of its correctness (i.e. is this the right type oflink between these two other semcards). Generally, a human-created linkwill not have a confidence value, or have the highest confidence valuepossible (except in cases where the human user isn't certain that whatthey are representing is correct). All links—like all semcards—have anauthor, whether an automated process or a human. This allows a user toperform searches and queries of the system specifying that links shouldbe authored by a human, or by the system, with a certain confidencevalue.

To avoid having an object semcard lose a referent target, whether adocument or other thing, the relationship between the two is implementedusing a Link semcard. A link semcard always connects two other semcards,the source and the target, making links directional. The semanticallyinverse meaning of any link can be defined in its ontology; e.g. theinverse of “author of is “authored by”. These links are themselves fullsemcards; there are typically no direct—or “flat”—links from a semcardrepresenting a target referent document and the referent target documentor item itself. This means that the link has rich information about therelationship between the semcard representing the referent target objectand the referent target object itself, allowing the link to bemanipulated in the same way as other semcards, via filtering of itsvalues and semantic dimensions.

In certain exceptional cases, link semcards can be “folded into” thesource semcard that it links to, to be treated as a “flat” link with noextra meta-data about the link itself. Optionally the whole Link semcardcan be folded into the semcard source. This is sometimes done forefficiency or convenience when moving semcards around in a computingdevice or on a network.

As mentioned, a semcard has a particular type which is typically definedin the system ontology. A user can expand and edit the types ofsemcards, either by adding to the ontology, modifying the ontology, oradding undefined metadata directly to the semcard. Such additions andmodifications can be shared with other peers using the semcard system.

The peer desktop application described here is a system for managingsemcards and semantic information; it is a general semantic browser, aswell as a dedicated application for managing semcards. The applicationhas several functional components which include 1) an identity manager,2) a user interface management component; 3) a database component; 4) anetwork component; 5) an automation component; and 6) a relationshipmanagement component. Providing more detail, each semcard peer node mayconsist of the following components:

-   -   Fuzzy matching engine for estimating conceptual distance between        semcards.    -   One or more schedulers for scheduling node events.    -   Monitoring module that computes statistics based on server        events.    -   Backup manager that manages backup schemes.    -   Manager for plug-ins that do e.g. mining, logging, monitoring,        schedule-based or event-driven behaviors, display rendering,        automatic linking, filtering, etc.    -   Test post facility, for testing semcards and queries before they        are posted.    -   Security, encryption and authentication manager.    -   System administration suite.    -   Router module that uses routing tables to forward semcards,        queries, offers, requests, etc. to and from other nodes,        depending on their meaning and priority.    -   Display units for displaying system statistics in various ways.

The identity manager manages the identity of the semcard managementapplication's users and groups, their communications, and the identityof match results for users and groups of users.

Another component addresses relationship management. This componentmanages personal information, essentially a user's identity or persona.It provides a secure way of managing the user's identity. It alsocontains data relating to all of a user's relationships and datanecessary to communicate securely with other peers.

The automation component operates as a single agent but broader than aconventional agent, which has a particular expertise. The automationcomponent has vast reach in the application in that it can communicatewith and utilize all other components in the system. It can specifyrules, e.g., rules ensuring that a user is valid, that new rules arevalid and that there are no detrimental effects caused by the additionor deletion of rules. Rules include permissions, automations, policies,and procedures, both those associated with semcards and those definedfor collections of semcards, and for the application in general. Theautomation component manages and executes automation in the background.The automation component provides the option for a single location whereall rules are stored and managed. The automation component is able toprocess exceptions and can intelligently respond to user through theuser interface; it has a knowledge base of user-interaction methods,including graphical, textual, phone (using speech synthesis), and SMS(short message service). This enables the automation component todetermine, using its interaction rules, how to interact with its userunder various circumstances. For example, if a user is not at a homebase, the automation component knows to send the user an SMS message.

The network component is an intelligent component that manages all datareceived by and transmitted by the application. This component managesand enables all peers, web pages, other networks, web services, otherdata sources to communicate with the system. The network component alsoknows when to alert other components based on the class of request orcategory of data entering the system.

The user interface component provides a user interface for the semcardmanagement application and has several sub-components. Referring to FIG.8, they include a hierarchical list of “entry points” 802 (“MyThings” inthe left-hand column), a filter panel container 804, a results panel806, and a viewer 808. The “entry points” column displays standard entrypoints into the semcard collection, such as type of semcard, as well asuser-defined entry points; often these are the entry points that areused most frequently. The entry points can also represent RSS (Rich SiteSummary) feeds, hard-disk folder hierarchy, and other traditionalelements on a computer system. Entry points can be time-dependent, forexample, an entry point could be called “Recently accessed,” which thesystem automatically ensures contains, at any point in time, onlysemcards that satisfy a particular set of criteria regarding time, e.g.that they have recently been created, viewed, or updated, or all three.

There are also “context” entry points. Contexts are a way to organizesemcards into hierarchically arranged categories. In a standardhierarchical setup of contexts and sub-contexts, a sub-context's inputis its super-context's output; hierarchical contexts thus being asemantic filter pipeline. Contexts can be applied to any entity whichfollows the object-with-properties model, as known in the art. Referringto FIG. 9, which presents a simplified example of contexts, a collection9-8 of seven semcards 9-1, 9-2, 9-3, 9-4, 9-5, 9-6, 9-7, of two types,rectangles 9-1, 9-3, 9-4, and triangles 9-2, 9-5, 9-6, 9-7, with varioussemantic attributes, as designated by squares and circles inside thesemcards, each attribute containing a value, as designated by the threeletters a, b and c. A semantic context panel 9-9 contains three semanticcontexts 9-10, 9-11, 9-12, that the user has created.

Referring to FIG. 10, to fill the contexts with relevant semcards, theuser associates 10-13 desired semcards 10-1, 10-4, 10-5, with context10-10, either by dragging them into the user interface or indicatingtheir association using other methods.

Referring to FIG. 11, when the user now selects the context 11-10(indicated by black), on the right-hand side of panel 11-9 pointers11-14, 11-15, 11-16 appear pointing 11-17, 11-18, 11-19 to thosesemcards 11-4, 11-1, 11-5 which the user had dragged into the context.The pointers are created by using the GUID of the semcards; the semcardsthemselves reside in a repository. To the user, the title of the semcardmay be used as the name of the pointers, for easy association. When thecontext 11-10 is selected, the context does a query to find all thesemcards which belong to it, by doing a query against a semcard storage.

Referring to FIG. 12, a sub-context 12-20 to context 12-10 can becreated. The user now associates 12-26 other semcards into this context,but one of the semcards, 12-4, is the same as was associated with thiscontext's 12-20 super-context 12-10.

Referring to FIG. 13, when the user selects context 13-20 (indicated byblack), three pointers 13-21, 13-15, 13-22 appear which point 13-23,13-24, 13-25, to the semcards 13-2, 13-4, 13-7 which were associatedwith this context 13-20 by the user.

Referring to FIG. 14, the user now selects context 14-10 again(indicated by black). Now pointers 14-14, 14-21, 14-15, 14-16, 14-22appear that point 14-27 to the semcards 14-1, 14-2, 14-4, 14-5, 14-7which are included both in context 14-10 and context 14-20.

Referring to FIG. 15, the user can now associate automation rules withthe contexts. Here the user associates 15-23 a rule collection semcard15-24 with context 15-10. The rule semcard may contain any number ofrules 15-25 pertaining to this context, involving such things asautomatically associating semcards with certain features with thecontext, deleting semcards, doing certain operations on the semcardcollection in the context given certain events, and automatically makinglinks between the semcards, inside the context or outside, according tocertain principles, etc. Automation rules apply either to only thecontext that they are attached to, or to that context plus all itssub-contexts. Typically, rules apply only to the context they areattached to. Rules relating to all contexts can be added in the semcardmanagement application as global rules.

Rules associated with a context can specify particular kinds of linksthat should be created automatically between particular kinds ofsemcards, given particular events. The rules can apply to only what'sinside the context or to how what's inside the context should bemanipulated relative to semcards outside the context. For example, rulesfor creating links between semcards in a context can be different fromthe rules about creating links between semcards inside a context andoutside it.

Referring to FIG. 16, a selected context or entry point 16-20, filteringa subset of the semcard pool to be shown in the results panel 16-39,allows the user to select one of the semcard references 16-22 to bedisplayed in detail in viewer 16-44. Rows 16-41 of meta-tags 16-42 andmeta-values 16-43 are displayed, along with the semcard's header 16-40.Tabs 16-45, 16-46, 16-47, 16-48 allow user to select various ways todisplay the semcard in viewer panel 16-44. The viewer panel allows usersto view semcards in various forms.

These forms, shown as tabs, include a “Summary” view, a “Related” view,a “Preview” view, “Visualize,” and “RDF” (Rich Data Format). The viewerpanel 16-44 shows a rendering of this semcard 16-22 according to itsdisplay policies for a form layout.

Referring to FIG. 17 a column header 17-26 is used to organize the namesof various selected semantic dimensions 17-27, 17-28, 17-29, 17-30 sothat the values of these dimensions 17-31, 17-32, 17-33, 17-34 for eachsemcard 17-21, 17-15, 17-22 listed in the results panel 17-39 can beused to sort them according to those values; the user can select asingle dimension to sort by. For example, if the values are strings, thesemcards 17-21, 17-15, 17-22 can be sorted based on their unique valuesfor that dimension.

A second way to sort using the column header is to sort by one dimensionfirst, then by another, then by a third, for as many dimensions as theuser wishes. This would allow the list to be sorted, for example, bytime first, then alphabetically according to name, etc. One way that theuser can do this is by specifying the order of each dimension in thecolumn header, for example, to sort first by dimension 17-32, dimension17-32 would be placed where dimension 17-31 is. This way, re-arrangingthe order of dimensions in the column header determines the order bywhich the semcards listed in the results panel are sorted.

The contexts can be used to support manually-initiated creation ofmultiple links, as when the user applies a command to create links of aparticular type between two types of semcards for all semcard instancesof those type in a given context.

The contexts can be used to support collaboration between the system'sautomated link generation mechanisms and the user. After a set ofsemcards have been added to a context, and links between them, thesystem can use these existing examples to present a more wisely chosenset of Links when the user wants to create more links between thesemcards within the context. The system can also create linksautomatically with higher confidence values, based on the positiveexamples of links created manually by the user.

A user can share one or more of her contexts with any other user withwhich she has relationships, via the sharing mechanisms describedherein. A user can also offer contexts using one or more Offer semcards.

Contexts can be used as a way to indicate which project a user isworking on to other users on a network: When a user selects a context,this context is flagged as the context that the user is currentlyworking in. For example, if the user selects a shared context called“project x”, this selection can be reflected in his co-workers' semcardmanagement applications or other application designed to reflect thestatus of co-workers. The behavior of this feature is controlled via thecontext's rules.

A user can also select a current working context and perform operationson the peer containing the context. These operations may not be directlyon the context or the semcards within the current working context. Forexample, the user may perform Web searches, creates documents andfolders, create graphics, and so on. All these operations, plusoperations directly on the current context and the semcards, areautomatically associated with the current working context and therelevant semcards.

The contexts can be used to do what is called “programming by example”in the art. To do this, a user creates a context and fills it with“example” semcards. Then she instructs the system to extrapolate, orgeneralize, rules based on the sample semcards. This can be as simple asone step (e.g. a button click) or, alternatively, the user can giveconstraints about the rule creation such as “only apply this to newsemcards received from relationships A, B and C”. The system will thenuse inferencing and rule creation mechanisms to extrapolate rules from acreated context. The user has several options for doing this. One is tocreate a context and fill it with semcards manually over a period oftime (days, weeks), such that when the extrapolation command is given,the system has a rich history of the user's manipulation and use of thecontext on which to base its generalizations. Optionally, any subsequentmanual additions or deletions from and to the context can be a triggerfor the system to revise its extrapolated rule set for the context.

The semcard management application has a filtering mechanism whichallows a user to quickly select a subset of the full set of semcardinstances available. Filtering is done for the purposes of finding aparticular semcard instance, for example, or zero in on a particulardesired subset of semcard instances. The filtering is based on acollection of filter panels and freestanding rules. The rules determinewhich features, of the total feature set represented by the semcards inthe semcard pool, are presented in the interface, allowing the user toselect from the multitude of semantic dimensions represented in thesemcard pool, and the values that these dimensions hold. The filterconsists of pre-conditions, which must be matched for the filter to fire(become active), a human-readable label, the property being filtered,and optional value(s) being filtered.

Referring to FIG. 18, a set—or pool—of semcard instances 18-8 containstwo types of semcards, triangles 18-2, 18-5, 18-6, 18-7 and rectangles18-1, 18-3, 18-4. These have semantic dimensions, represented here withwhite squares 18-10, black squares 18-11, white circles 18-8, and blackcircles 18-9. Each dimension contains a value, represented with theletters a, b, and c. The semcard types triangle 18-15 and rectangle18-16 are defined in the ontology 18-13, as are their semantic dimension18-17, 18-18, 18-19, 18-20 and the types of values 18-21 that thesedimensions can accept. (Notice that an implementation of the inventionwould likely use strings instead of the graphical icons used here, forillustrative purposes, to represent these concepts, or a combination ofboth. Independently of the way a concept from the ontology isrepresented to the user, each concept in the ontology will simply beidentified with a unique ID.)

Referring to FIG. 19, a filter container 19-23, shown as box X, holds afilter panel 19-24, a user interface concept, which displays two symbols1925, 19-26. These symbols represent the types of semcards in thesemcard pool 9-8 shown in FIG. 9. The user can choose either of thesesymbols (e.g. by clicking) to designate a subset of the semcard pool, inother words, to apply that filter to the semcard instances in the pool9-8. In the context of filter panels, the semcard types, their variousdimensions, and the values, are referred to as “features”. Rulesdetermine which features are available for the initial filter panel, aswell as each subsequent filter panel that appears as the user selectsfeatures in each one.

Referring to FIG. 20, showing a second state of the filter containerlabeled Y, after the user has chosen feature 20-25 in first filter panel20-24, such that some of the semcard instances in the pool 9-8 have beenfiltered out (namely all semcards which are not of type triangle),resulting in a subset 20-28 with only triangles 20-29, 20-30, 20-31,20-32. Further, a second filter panel has appeared 20-26, containing aset of features 20-27 for further narrowing down the subset of semcardsfrom the semcard pool 9-8.

Referring to FIG. 21, showing a third state of the filter containerlabeled Z, the user has further selected a white circle feature 21-33,resulting in a new filter panel 21-34, with a set of features 21-35 thatcan be used to further reduce the pool of semcards. The selection of21-33 has reduced the subset of semcards 21-28 to the three semcardinstances of type “triangle” which all contain a “white circle”dimension 21-29, 21-30, 21-32.

Referring to FIG. 22, the user selects value 22-38, this time reducingthe subset of semcards 22-28 to a single semcard of type “triangle”which has a semantic dimension of type “white circle” which contains avalue of type 22-38.

Because the filter rules are free-standing, it is possible to applyfilters to filters, providing a powerful way to program the way certainsemcards and their dimensions and values can be filtered in theinterface.

Referring to FIGS. 8 and 23, both screenshots from the user interface ofthe semcard management application the filter panels have two possiblelayouts: one in which the panels are displayed across the panel as shownin container 804 in FIG. 8. and another in which they are “stacked” ordisplayed on top of each other as shown in container 2301 of FIG. 23 ina way that only the selected feature labels, 2302, 2303, and 2304, arevisible to the user after a selection of the feature has been made. Thelatter method leads to a visually appealing display and is spatiallycompact allowing more space for the viewer panel and results panel.

Referring to FIG. 24, each filter container X, Y and Z shows the“stacked” states of the filter panels, corresponding to the same statesof the filter panels marked X, Y, and Z in FIGS. 19, 20, and 21,respectively. In the “stacked” version shown in FIG. 23, when a featurehas been selected, the filter panel gets “stacked”, and is given atitle, such as “Documents” and “Authored By”, that corresponds to thefeature that was selected, as will now further be described.

As mentioned, filter rules can have human-readable labels. These can beused in the display to make the features more readable, e.g. instead ofa feature list containing flat labels such as the list {semcard:Document, author: Joe, owner: Frank, moderator: Sue}, the list can beembellished with natural language phrasing such as in this example: {adiscussion, authored by Joe, owned by Frank, Sue is moderator}, etc. Thegeneration of human-readable labels is managed by a combination of localrules stored with each filter rule, and by a set of global rules thatapply to the whole set of filter panels, and whose job it is to make thepath chosen by the user read more like a sentence than a series of nounsand verbs. To take an example, referring to the filter containers X, Y,and Z of FIG. 24, instead of listing the filter path as {a triangle, awhite circle dimension, value is a}, the tags could read {a triangle,with a white circle, containing the value ‘a’ }. This feature becomesespecially important in the alternative display of filter panels shownin FIG. 24 where the filter panels are stacked.

The filter mechanism of the semcard system can use one or moreontologies, which can be used for determining which filters areavailable for any given state. For example, any node above a set ofsub-nodes node in the ontology can be considered a “stop flag” node, inthe following way. Any dimension which is defined in a sub-node is notdisplayed per se, but instead its stop flag node, which is higher up inthe ontology, is displayed. Referring to FIG. 18, the white square couldbe set as the stop flag for the black square, and the white circle couldbe set as the stop flag for the black circle.

To navigate backwards in a previously chosen path such as that shown inFIG. 21, the user simply selects any feature in any of the displayedfilter panels. In the alternative layout in FIG. 24, the user re-selectsa prior feature, e.g. the triangle 24-25 in layout Z, to go back to seethe features in that panel. The semcard management application alsoprovides forward and backward arrows that allow users to navigate onestep (selection) at a time back and forth.

The semcard management application enables users to save a query createdby any other method, as a named “views”—software objects identified inthe interface with a human-readable label or icon. Selecting a view(e.g. by clicking) will run the query again on whatever set of semanticobjects it is applied to (i.e. its input), as selected by the user inthe interface. Alternatively, a view can be set to update its result set(by running its query) on a periodic basis, or event-driven based onother events such as every time a new semcard is posted, based onstandard subscription mechanism, or based on various events in remotesemcard collections, such as for example those located with a remotesemcard management application elsewhere on the network.

There are at least two ways to represent visually the effect of aselection of such a saved query. One is to display the full set ofselected filter panels again, as they looked when the query was built.The other is to hide this path and show only the semcard set resultingfrom the query in the results panel. The latter may be better if theuser wants to further extend the query with other subsequent semanticfilters; the former is better if he wants to modify any existing part ofit. Views can be moved around in the interface as any virtual objectsuch as contexts, and its input can be freely selected, even after ithas been created, by, for example, copying a view from one context toanother, or using it as an entry point.

It is worth noting that filter panels as described are not dependent onsemcards; they can be applied to any set of objects with properties, asis known in the art.

A view can be shared with anyone by representing it with a semcard thatis shared with other users in the way semcards are shared, viarelationships.

The database component provides data storage for semcards and, can haveany type of underlying database. Semcards and ontologies are stored,accessed and searched in the database component, as are credentials andencryption keys.

Finally, the semcard management application of the present inventionalso has Relationship Management capabilities. It allows a semcardapplication system user to communicate intelligently with other peersexecuting the semcard application system in a seamless manner. It allowsusers to share semcards they have created with other peers.

Semcards can represent relationships between people. On acomputer-mediated network, semcards can be used to control and automateseveral aspects of relationship management. In the semcard managementapplication relationships are managed via Relationship semcards. TheRelationship semcard stores all information relevant to a relationship,including the parties, their permissions, and the type of automatedinstructions related to the relationship. The automation componentmanages the execution and maintenance of relationship-related rules.

A relationship establishes a virtual communications channel between theusers. By default, unless a relationship is formed between the users, nocommunication channel between them exists and thus they cannot directlyinteract with one another. (An exception to this is where indirectcommunication can be achieved via various mechanisms, described below.)

The semcard management application is hard-coded to treat theRelationship semcard with top security. By default the Relationshipsemcards are non-sharable and non-cacheable except through speciallysecure protocols.

To the user, the Relationship semcard appears as an ordinary semcard. Ithas the same interface as other semcards, and can be manipulated in thesame way by its owner, containing links to semcards in the semcardspace, facilitating navigation, including the people involved, theirinteraction history, interaction rules, etc.

In creating a relationship, one party, the sender, initiates itscreation, by posting a relationship semcard invitation. The Invitationsemcard can be made to include a unique address that enables therecipient to reply only this particular invitation, and which can be setto expire after a certain time, as well as based on various events suchas the recipient trying to reply in ways which are not allowed by theInvitation semcard's policies.

The receiver has the ability to reply with an acceptance, decline,cancellation, or counter-invite. When they have been posted, semcardsrepresenting relationships can be in one or more of the followingstates, without being limited to this set: (a) Introduction, (b)invitation, (c) accepted or (d) declined, (e) in negotiation, (f) policychange, and (g) terminated. In all cases a reply is returned to thesender with the exception of cancellation. A counter-invitation has thechoice of being accepted, declined or cancelled by the sender (there isno counter-invite to a counter-invite—the next step would be a new offerfrom the sender). A Relationship semcard can have a pre-built protocolthat determines the transition of the semcard between these states, aset of pre-built, single-action reply per state (the equivalent ofbuttons), as well as an alternative free-form reply, for each state ofthe relationship creation.

If the recipient opts-out of the relationship, i.e. does not agree withthe terms, does not reply to the invitation within its time-to-live(same as manual cancellation), or replies with a rejection, then therelationship will not have been established. The only type of semcardthat can be shared in the absence of a mutually-approved consentingrelationship is an Invitation semcard.

When a user targets a semcard at another party (using an e-mail addressor semcard system ID/alias), for sharing or offers/requests, or alerts,the system first checks to see if the parties have an establishedrelationship. If no relationship exists, the initiating party is firstprompted to fill out an Invitation semcard. The Invitation semcard is atransaction/process semcard whose states are specific to starting andnegotiating the terms of relationships. The Invitation is delivered tothe other party as plain text email with a MIME attachment of theInvitation semcard, as well as an inline URL that links to an on-linehosted HTML version of the Offer semcard. If the recipient has thesemcard system, they can use the MIME attachment directly. If they donot have the system, they can either download the application, or aviewer applet, or they can use the on-line HTML version. Through one ofthese means a receiver views the Invitation semcard to fill out.

Once they have received a relationship Invitation, they fill in theirside of it, and then reply via a pre-configured button on theRelationship, which is one of “Accept”, “Counter-invitation”, “Decline”and “Cancel”. If both sender and receiver have the semcard system, therecipient now has the Relationship semcard in their semcard managementapplication. If they do not have the semcard system, they can access therelationship via the hosted on-line account via the included URL,regardless of whether the party has the semcard system. However, thisfeature may place significant limitations in terms of the number ofrelationships it supports, how many semcards it can store, as well asand security control.

If a relationship already exists, then the semcard system delivers thesemcard according to the optimal combination of (a) relationshippreferences of the recipient for how they want to receive it, and (b)the best currently available mode of delivery.

Like all semcards, Relationship semcards can be set to have a time tolive (TTL), as can invitations and any step of the process of forming arelationship.

In the semcard management application one or more relationships mayexists between any two semcard management application users; with anymultitude of permissions, instructions and access control that appliesto either party that will be stored with their one or more Relationshipsemcards. For example, if user A has given user B permission to view(and optionally cache on their own system) a set of semcards on A'ssystem, and A has given a group of users, of which user B is a member,permission to view another set of semcards on A's system, then user Bhas access to both sets of semcards on A's system. Relationship semcardscan represent any form of current Internet relationships, such as email,instant messaging, discussion groups, etc.

By default, relationships are bi-directional. Both parties give eachother access to information in their system. Policies and rules aretypically agreed upon during the creation of the Relationship. However,policies can be modified by either side any time during therelationship. For such changes, the parties can decide whether the otherparty is notified of the changes, or gets to approve the change. In abidirectional relationship the initiating party (sender/inviter) alwayscreates an invitation for a relationship.

Relationships can also be uni-directional. In a unidirectionalrelationship, only one party has access to another's system.

If one party in a relationship wants to change (increase or decrease)the access they have to the other party's system, they can issue aRelationship Modification Request for those changes. The owner of thesystem in question will then have to accept the request in order for thechange to go through. The steps follow the same pattern outlined forcreating relationships, with the exception that the new Relationshipsemcard automatically inherits all policies of the previous Relationshipsemcard, except for those that have been changed.

An on-line semcard application system service provides lookup for allsemcard system users to allow them to make direct peer-to-peerrelationships for making offers and requests. How the semcard systemusers discover each other can be (1) by browsing, if a party has madetheir contact info available on-line in human-readable andmachine-readable formats; (2) by discovery via hosted on-line lookupservice, using the name of other party and/or keywords or passwordsexchanged between the parties, as well as (3) direct hookup between thecomputers via exchange of IP addresses.

In a number of cases, a semcard system user may want to make subsets oftheir semcards available to whoever is interested. This can be done byhaving a relationship with the public, which is a relationship hosted byan online semcard service provider. (This relationship is also the onethat users use to allow anyone to post Relationship invitations to them)By setting the policies on the Public Relationship, semcard applicationsystem users can open up various parts of their semcard collection tooutsiders on a pull-basis, or as the related rules prescribe.

Setting permissions and default policies for relationships can be donevia a How tab on the Relationship semcard, as shown in FIG. 25. Lookingat the Who tab will bring up information about each member of therelationship, provide an overview of their permissions, and providelinks to the specific details of these policies for each member. Thisenables one quickly to locate the policies for any member of therelationship. For example, if one wanted to change the policies for aparticular member, the fastest way to do so may be to go to the Who tab,locate the person alphabetically, look at the list of policies besidetheir name, and click on the one which needed to be changed; this wouldinstantly bring up the right policy for that person in the How tab. Aspecial section for custom rules holds extensions and shortcuts to theother rule panels. Rule semcards can be linked into this area for aquicker way to set policies for the relationship. Thus, a user couldlink the rule semcard for their “friends” relationship directly to anewly created relationship, to have the rules for the new relationshipbe identical to their “friends” relationship. There are two levels ofrules and policies in a relationship. Level one contains the standardpermissions as listed in the examples above. Level two concerns rulesabout the relationship itself—who can change it, cancel it, who canmodify its policies after it's been created, etc.

Whitelists and blacklists are UI constructs to quickly assign global,top-level rules about sharing for any set of semcards. Furthermore, awhitelist and blacklist can be used in the system to selectively controlrules for Relationships. Using a combination of semantic and fuzzycategorization, the system can classify Invitations based on the levelof authentication and trustworthiness of their author. Whitelists are away to set global settings quickly for all members of a relationship onall general dimensions, such as caching permissions, forwarding,duplication, copying, etc.

Using semcards to hold metadata, policies, and automation instructionsabout a relationship, combined with a comparison mechanism as describedin FIG. 25, users can control in detail: (a) Who can send them what kindof information, (b) Who can search, view, and operate on which semcardsand their referents in the user's possession, (c) Automation, such aswhat kinds of events, initiated by people or processes with whom theuser has relationships, trigger what kind of automatic system responses,(d) What kinds of services are available on one computer or account forthe other party, such as caching of data, processing and matching,forwarding, (e) What kinds of notification one account should give theother. These rules can be defined hierarchically, to resolve conflictsautomatically; general rules about the relationship generally takeprecedence over rules applying to a single incident of sharing, forexample. They can also allow exceptions, by asking the users whetherthey want to override global rules, when a conflict is detected.

Referring to FIG. 26, computational devices 26-1, 26-2, 26-3, 26-4 areconnected via a computer-mediated network 26-6. Each device has acomputer-readable storage medium 26-5, 26-7, 26-8, 26-9, on whichcomputer-readable entities and a knowledge base containing semcards isstored. Semcards 26-12 and 26-10 represent relationships. Semcard 26-12,owned by user A, references 26-11 semcard 26-10. Together, 26-12, 26-11,26-10, represent a uni-directional relationship between owner A ofsemcard 26-12 and owner B of semcard 26-10, where user A has auni-directional relationship with user B. To control this, semcard 26-12references 26-13 semcard 26-14 which contains rules about what kind ofsemcards and data user A can send to user B. Rules in semcard 26-14determine the terms of the relationship that 26-12 and 26-10 have,including those described below.

Referring further to FIG. 27, a bi-directional relationship 27-16,27-20, has been established between user C on device 27-3 and user D ondevice 274. Semcard 27-19 sets the rules (access and sharing policies,display and automation policies) about what data user C can push (post)to user D, and what kind of pull (queries, browsing) user C can do onuser D's device; semcard 27-21 sets the same rules about D's access andpermissions on C's device. In other words, semcard 27-19 controlswhether user C can send data to user D and whether C can browse or queryuser D's semcards and data. Semcard 27-21 controls whether user D cansend data to C or browse or query against C's data.

Semcards 27-14, 27-19, 27-21 also hold rules about relationshiptermination, backup, bandwidth, and other issues that pertain to eachrelationship, and the actions that can be supported by the system foreach party.

The rules pertaining to push and pull can be replicated for eachparticipant on the owner's peer, such that all users have a copy of therules they have shared with the party they have a relationship with. Inthis case, for relationship 27-20, semcard 27-19 would hold pushpolicies for the direction from user C to D, as before, but semcard27-21 would hold a copy of these rules; rules about pull by D from Cwould also be stored in semcard 27-19, and a copy would be stored insemcard 27-21. This would then be replicated for the relationshipdirection 27-16. The benefits of this arrangement is that should user Aviolate policies on his peer regarding what he is allowed to push touser B, through a malicious act or a failure of the system, user B'speer, now receiving data from A which is not allowed to be sent to B byA, can notify B that user A is in violation of their agreed-uponrelationship policies.

Multi-party, or group, relationships can also be supported usingsemcards. Such group relationships may be established in various ways,including the following way: Individual one-on-one relationship semcardinvitations are sent from the inviter to all named parties in theproposed group. All messages go to the originator of the relationship—nonegotiation happens between any two invitees until the originator hasgotten an acceptance from both of them. In one variation of thismechanism, parties cannot communicate other types of semcards with oneanother, until all parties accept the terms of the group, as set by theinitiator of the group. Another way of establishing groups is by using aunique ID for the group, to which any semcard can be addressed. Themembers of the group will then subscribe to the group (via its ID). Theycan put filtering on the group, such that only particular semcards reachthem, as described elsewhere in the present invention.

The unidirectional relationship 27-11 has been extended to abidirectional relationship 27-23, between the owners of semcards 27-12and 2710; policies 27-30 have been extended for controlling therelationship 27-23 from 27-7 to 27-6. Further, a bi-directionalrelationship 27-26, 27-27 has been established, making up a completebi-directional group relationship between owners of semcards 27-12,27-15 and 27-17. Alternative implementations of such grouprelationships, for linearly scaling to large groups, can be achieved byusing servers, as described in the literature, and with the benefit ofusing semcards to represent such relationships. Semcard 27-14 has nowbeen extended with rules pertaining to relationships 27-15 and 27-17;semcard 27-19 has been extended with rules pertaining to relationships27-10 and 27-12; semcard 27-21 has been extended with rules pertainingto relationship 27-12. Further, a uni-directional relationship 27-28 hasbeen established between relationship semcard 27-17 and 27-10; semcard27-30 has been extended with rules pertaining to relationship 27-17.

A relationship can also be created by a user for some set of thirdparties, without including themselves in the group. In one embodiment ofthis system, the user sends an introduction semcard to two or morethird-parties. The third parties establish a relationship according tothe methods described above. In one variation, a party may only do thiswith other parties whom they have already established relationships,unless those parties have explicitly stated in their global relationshippolicies that they accept such unsolicited relationship invitations.

Relationships and introductions can be accepted or declined manually orautomatically. In one embodiment, once established, if either partychanges the relationship semcard in any way, relevant parties in therelationship will be notified of the change, at which time they mayignore/accept the change, or they may modify their policies or terminatethe relationship if they disagree with the changes.

In one embodiment, a user may maintain more than one relationship toanother user—for example they may have one relationship for “personalcommunications” and another for “business communications” with the sameparty, each with different policies, identities and addresses. In such acase, a user might terminate one of these relationships, but would stillbe able to interact with the other party via the remaining relationship,according to its policies, etc.

When creating a relationship, a user can choose which of their rules arevisible to the other party, and which are hidden. Further, the user candecide if the hidden parts of the relationship are exported to the otherparty's peer or not. If they're not exported, they are more secure fromunwanted exposure to the outside. However, since they can only beenforced on the owner's semcard management application peer, this meansthat the flow of data from the other party cannot be controlled at thesource on their peer.

A user establishes relationships with other users by exchanging offersand requests for relationship Invitations semcard among user accounts. Arelationship Invitation is a semcard that contains choices forresponding to the invitation that encode acceptance or rejection of theproposed relationship. Only when both users to a potential relationshipmutually accept relationship Invitations to one another is therelationship initiated. If the receiving party does not have the semcardpeer application, the Invitation goes via regular email to them aseither an HTML form, or a URL that points to a Web page where they canchoose to accept or decline the invitation. Even when users have norelationship they may, however, be able to interact and share indirectlywith one another via relationships they have to other uses and sequencesof relationships that connect them indirectly. Once they have a director indirect relationship, users may then route and match offers andrequests for information to one another, browse and query each other'ssemcards, according to access policies.

When users have a relationship they can exchange semcards of varioustypes that serve the purpose of communication between the parties. Forexample, a user can fill out a semcard called “note” and address it to aparty with which they have a relationship, replicating thefunctionalities of email, but with the full benefits that semcards,Relationship semcards, and the semcard management application provide.Further, users may specify the mechanism by which the recipient of suchcommunication should be notified—whether by a pop-up message, a “flag”,sound, or by other means. They can also specify the urgency of suchnotification, such that the recipient's semcard management applicationcan apply rules as to how best to notify the recipient of thecommunication. Policies of the sender will specify (a) the preferreddefault way of notifying the other party of communicative actions (and,in fact, of any sharing event or other communicative event on therelationship), and (b) what the rules are for various urgency levelsselected for such events. The recipient may have specific rules for therelationship about what kind of events thus specified by the sender areallowed to be followed on their side. This is mirrored for anyinteraction in the other direction. Global rules may also be set for allrelationships, or specific groups of relationships.

An extension of this design relates to instant messaging between the twoparties. Rules about when each can be accessed, when they are listed asbeing “available” for chatting, etc., can both be set per relationshipas well as globally for groups of relationships or all relationships.

The system of the present invention is capable of intelligent matchingof offers and requests, involving all types of knowledge: Information,ideas, suggestions, opinions, products, services, jobs, events, people,skills, etc, using semcards and semcard-like structures, creating abi-directional marketplace on the Internet. The invention enablesparties to search and do marketing in the same way, in the sameenvironment. This reduces the complexity of finding matches to offersand requests, which often involves both searching for others andmarketing so that others can search for you. The system also helpsproviders search for seekers who want what they offer and enables“reverse search”, a bi-directional network is created, doubling theutility of the uni-directional nature of the Internet for thesepurposes, as described earlier.

Semcards, and knowledge networks, can be designated as being offers orrequests on a computer network, for various purposes, including (a)advertising, (b) offering of merchandise, or (c) finding or procuringitems. This can be done in at least four different ways: If a singlesemcard is being offered/requested, metatags in the offered/requestedsemcard contains the offer/request metadata. If a single semcard or aknowledge network is being offered/requested, a separate semcard canhold the offer/request metadata. In the latter case, the separatesemcard can either wrap the offered/requested semcard or knowledgenetwork, or refer to the semcard or knowledge network using one or morereference pointers.

Offers and requests are thus semcards or similar-structured softwareobjects, comprised of meta-data that defines the attributes of theparticulars regarding the offers and requests they represent, and wherethe payload describes what is offered or requested, such as jobs,resumes, opportunities, products, services, etc. Users can manuallycreate offers and requests for things using the system user interface.In particular this can be useful when representing things that have noelectronic substance, such as ideas or things that are not representedby documents or files on a computer.

Parties create forms by selecting the appropriate form templates from adirectory of alternative form templates for various purposes and thenfill out the relevant parts of the semcard, optionally linking them toother semcards and/or target reference, and post them to the network.There are at least two types of addressing a semcard that enable both“direct” and “indirect” targeting or routing, for purposes of sharing,or offers, requests, invitations, and other types of targeted—orgoal-directed—semcards. With direct targeting a semcard is sent toexplicitly named recipients with which the semcard's author has anexisting relationship. With indirect targeting, on the other hand, asemcard is sent to recipients who satisfy various criteria. An offer orrequest can be targeted to selected parties, loosely-defined on-linegroups of users, or to public forums. These targeted recipients can bedefined in a fuzzy manner, using a matching engine to determine thelevel of relevance of the offer/request to any party encountered, usingmatching mechanisms described below. Indirect targeting is useful forreaching unknown parties who are interested in a particular topic. Usingthese methods, the target audience can be defined as specifically orgenerally as desired by the sender.

When the semcard has been specified to the user's satisfaction it can betest-posted. Test-posting provides an estimate of how many matches mayoccur, how much the posting may cost, etc. The user may then tune thesemcard's goals policies to refine it based on this estimate beforeposting it. Users may repeatedly refine and test-post until they aresatisfied.

Another more advanced option is to have an on-line service evolve anoptimal semcard or set of semcards for a particular campaign. In thismode, the user provides some example semcards that represent their goalsand the on-line service will use various algorithms to evolve andrepeatedly test-post generations of similar semcards to arrive at asemcard specification that has optimal price-performance attributes.This semcard can then be posted by the user.

When an offer or request has been posted, it is routed over the networkin various ways, depending on what kind of semcard it is. Using semanticrouting, for example, semcards that represent offers, requests, andqueries, can be routed semantically between nodes on the network. Usingpeer-to-peer routing, direct relationships can be leveraged to sendsharing policies, notifications, alerts, and messages.

Referring to FIG. 28, computational devices 28-1, 28-2, 28-3, 28-4, 28-5are connected via a computer network 28-6. Each device has a computerreadable medium, on which semcards are stored 28-7, 28-8, 28-9, 28-10,2811. A semcard 28-11 is used to produce 28-13 a routing profile 28-14.The routing profile describes salient features of the semcard, asdetailed as deemed necessary for supporting efficient routing ofsemcards. The routing profile 2814 is propagated to other computers onthe network 28-2, 28-3, 28-4, and stored on their computer-manipulatablestorage media 28-8, 28-9, 28-10.

The profile does not necessarily point directly to the original homesemcard from which the routing profile was generated; a copy 28-19 ofthe original routing profile 28-14 may point 28-20 to the node 28-9 fromwhich it received the routing profile, as described in the art.

The routing profiles 28-15, 28-17, 28-19 serve as pointers 28-16, 28-18,28-20 in the direction of the node 28-1, 28-7 that hosts the semcard28-12 from which the original profile 28-14 was generated. If theoriginal semcard 28-12 represented an offer for something, the routingprofile will also represent this fact, and specify that it can match torequests for its metadata. When user of computing device 28-5 creates asemcard 28-21 that represents a request containing metadata that matchesthe original semcard 28-12, a request semcard will be routed 28-22 tothe nearest node 28-4, 28-10 on the network. If the receiving node 28-4,28-10, contains a routing profile that matches the semcard's 28-21, itwill route it to the node 28-9 to which the routing profile 28-19 points28-20.

Semcards can be routed using the same principle in a network withdedicated routers. Referring to FIG. 29, computational devices 29-1,29-2, 29-3, 29-4, 29-5 are connected via a computer network 29-6. Eachdevice has a computer readable medium 29-7, 29-8, 29-9, 29-10, 29-11, onwhich semcards are stored. A semcard 29-12 from which is produced 29-13a routing profile 29-14. The routing profile is propagated 29-27, 29-28,29-29 to the routers on the network 29-24, 29-25, 29-26. In the samemanner as before, a copy of the semcard which is posted/published ontothe network travels on the network 29-33 to the nearest router 29-26, atwhich point the router forwards the semcard to the closest router, andso on, until it arrives at the node 29-1, 29-7 where it was requested.

As explained in the art, two or more routing profiles can be aggregatedand compressed, to represent thousands of them in a single table. Arouting table is an aggregation of two or more routing profiles,degraded in specificity based on the distance to the home knowledge basewhose data it represents.

This can also be done with semcard routing profiles. Each routing tablewould contain partially aggregated and partially or fully compressedinterest profile of downstream semcards. Semcards representing offersand requests are passed on by routers to nearby routers that haverelevant interests, in a decentralized manner, until they reachedge-nodes where their content has been requested or is needed.

Routing tables can be propagated via semcard relationships, as canpublished offers and requests which are routed based on the routingtables.

When semcards have been routed to a recipient node or semcard deemedworthy of matching against, matching processes such as agents, scriptsor programs, can compare pairs of semcards to determine the level ofmatch between them. Such processes work continuously on behalf ofseekers and providers, enabling them to go off and work on other thingsuntil matches are found. The system understands the meaning of offersand requests and eliminates irrelevant search results by semanticallymatching them to each other. If seekers wants to find “rock,” they candirectly tell the system whether they mean “rock music” or “rocks andminerals,” which the system subsequently understands and can make useof.

Semcards can be compared on their slots, both semantic dimensions andvalues. Such comparison can be used for various purposes, including (a)routing, (b) matching, (c) one-of searching/querying/browsing, (d)standing offers/requests, (e) filtering, and (0 inferencing.

Referring to FIG. 30, semcard 30-1 composed of four parts 30-2, 30-3,30-4, 30-5, each segment containing a set of meta-tags and meta-data,and another semcard 30-6 composed of four parts 30-7, 30-8, 30-9, 30-10,the parts being for example a basic specification, a displayspecification, a policy specification, and an automation specification,each containing metatags and meta-data 30-12, 30-14, 30-16, 30-18 insemcard 30-6 and 30-11, 30-13, 30-15, 30-17 in semcard 30-1. The size orcomplexity of a semcard can vary. Comparison between two or moresemcards can proceed in two steps, the first step comparing theirmetatags, and a second step comparing their metadata.

Referring to FIG. 31, shown are the meta-tags 31-20 of a first semcardand the meta-tags 31-21 of a second semcard, compared or matched in acomparison module 31-19, using a plurality of comparison algorithms31-22, providing an output 31-23 of the similarity between the meta-tagsof the two semcards. The second step, comprising metadata 31-25 of thefirst semcard and the corresponding metadata 31-26 of the secondsemcard, and a comparison of these in a comparison module 31-24, using aplurality of comparison algorithms 31-27, provides an output 31-28 ofthe similarity between the metadata of two semcards. The output 31-23 ofthe first comparison module 31-19 provides a separate result for eachmeta-tag, and enables the next step in comparison module 31-24 to bedone more intelligently.

An offer, request or other semcard which is designated to be matched toother compatible semcards, has associated policies which determine howthe matching should be done. In one alternative, only metadata whosemetatags are identical between the compared semcards, are compared inthe second step. In another alternative, a continuous measure ofdistance (difference) is used, in combination with a threshold, is usedto determine if metadata for each metatag should be compared; if thedistance metric is larger than the threshold, the metadata for thatmetatag is not compared. Both meta-tags and meta-data can be comparedusing an ontology, if they are defined using one. However, even if onlymeta-tags, or neither meta-tags nor meta-data, are defined using anontology, comparison can still be performed, using different methods,which include string comparison, synonym comparison, or other suchcomparison mechanisms as described in the art.

Matching or comparing a collection of semcards, i.e. a knowledgenetwork, is an extension of the above principles. In its simplest form,each object in the collection is compared to each object in the othercollection, and the number of exact matches is counted and used as adirect measure of similarity. A more advanced embodiment of thisincludes using e.g. an ontology or taxonomy to generalize the type ofobject, for example, if an object of type dog is compared to an objectcalled animal, and their relationship can be determined by the use ofone or more ontologies, or by some other means, the similarity measuredoes not simply mark them as dissimilar, but calculates a measure thatrepresents the distance between the two objects and their meta-tags andmeta-data. Even though the semcard of type animal may be different fromthe one of type dog in many ways, dog is a subtype of animal, and thuswill have more similarities than a dog and a table. Another embodimentcould ignore the type altogether and compare a dog and a table semcardby first comparing their semantic dimensions, both of which may containthe meta-tag “number-of-legs”, which may contain the value four. In thisscheme, the similarity between a millipede and a table may be judged tobe less than the similarity between a dog and a table, if “number-oflegs” is one of a few semantic dimensions being compared, because both adog and a table have four legs.

Knowledge networks that is offered can be represented by a collection ofOffer semcards, a single Offer semcard, or a compound hierarchy of Offersemcards, where the network is described at various levels. In this lastcase the matching algorithms “know” about the network's structure, andcan match intelligently to requests for various parts of the network aswell as the whole network.

Typically, offers are matched to requests and requests are matched tooffers. It is also possible to offer requests, and request offers,making it possible to distribute collections of such semcards in one go.In a routing network, whether peer-to-peer, client-server, semantic,other type of network, or some hybrid, a subscription is represented as(a stationary) routing table entry that typically lives on a particularserver; a publication is routed in the network—i.e. it travels towherever there are stationary relevant subscriptions. An offer orrequest can be posted either as a subscription, a publication, or both.The decision as to which of these is used for any instance of a postedsemcard can be made based, among other criteria, on (a) relativefrequency of offers vs. requests, (b) network bandwidth, (c) computingpower of the computational devices on the network, etc., and it can bemade dynamically and automatically by the system based on various statesof the network at different times, or hard-wired into the network androuting mechanisms.

There are thus three different matching combinations for published andsubscribed offers and requests: (a) published offer and subscribedrequest, (c) published request and subscribed offer, (c) a combinationof options (a) and (b). The first represents the traditional situationwhere people are matched up if one of them has something to offer andone has something to request, where requests are stationarysubscriptions and offers are published onto the network. Option (b) isthe inverse equivalent of (a). For any network, a decision has to bemade whether either options (a) or (b) are hard-wired into the networkdesign. The subscription is typically offers more security because thesemcard itself is only propagated anonymously into the routing tables,so the choice of this option may actually also be left to the user. Insuch a system offers and requests can be either publications orsubscriptions. Of course, should the user choose to post an offer as asubscription in such a network, the user will only get matches onrequests that are publications, hence reducing the potential number ofresulting matches. Alternatively, option “c” makes it possible to chooseboth. The choice as to the network design can be made based on severalcriteria, including but not limited to (a) security requirements of thenetwork, (b) available bandwidth (network and computing power), and (c)desired simplicity (doing both is more complex).

Once matches are found, various further activities may then take placeaccording to the specifications of the matched users or parties. Forexample, one or both users may be notified or they may receive thematching form, or manual or automated activities may take place totransfer files, buy or sell things, reply to one another, forwardmessages to other parties, launch external applications, etc. Thesefurther “follow-up” activities can be manually initiated and completedby users, or they can be automated by software agents, scripts orprograms attached to user accounts and/or to particular relationships,offers or requests. The system's automation processes can follow up ontasks, according to the rules specified for the offer or request bytheir authors, allowing automatic processes to respond, issue alerts andnotifications, transfer files, make or accept payments, etc., on theirbehalf. The automation processes can also help the matched partiescommunicate by facilitating anonymous or authenticated interactions.

Identity or the authenticated person in the semcard is typically storedas either encrypted or non-encrypted data. The identity section in asemcard has four parts:

The author of the semcard

Recipients of the semcard

Parties who have rated the semcard

Parties who have annotated the semcard

If the semcard is an offer or request, this information is added:

Parties that have matched and have been notified about the semcard Eachof these can be hidden or revealed based on the semcard policies asshown below.

Semcard

Goal:

-   -   Offer    -   Request    -   Alert    -   Invitation    -   Other

If offer or request, match to:

-   -   Other offers of type [default: same as this]    -   Other requests of type [default: same as this]

Security level: [high] [medium] [low] [custom]

-   -   Encrypted:        -   Yes [how] [level]        -   No    -   Escrow:        -   Yes        -   No

Network transport:

-   -   Subscription (stays on node)    -   Offer (travels on network)    -   Both

Notification:

-   -   Sender    -   Recipient    -   Both    -   Either    -   Neither

Authentication:

-   -   Sender    -   Recipient    -   Both    -   Neither    -   Either

Anonymity

-   -   Sender    -   Recipient    -   Both    -   Neither    -   Either

As mentioned above, the decision about when and how to contact twoparties of a matching offer and request is based on the rules andpolicies of the two semcards. Rules can be specified for every part ofthe process. The rules also dictate the matching process. For example,rules may include how exact or fuzzy the matching should be for eachfield, field priorities, which fields are required to be matched fornotification to occur, how notification should be handled, what kind ofuser authentication is required for a match to occur, how the semcardauthor's identity should be hidden or revealed to matched parties, etc.Available policies include:

-   -   Notification    -   Matching    -   Payment terms and policies    -   Sponsorship terms and policies    -   Identity    -   Privacy    -   Certification or Authentication    -   Security policies    -   Reply policies    -   Browsability    -   Receipts    -   Payment terms and conditions    -   Billing terms and conditions

A price can be attached to the launching of a semcard; the pricerepresents a function of the system-cost in routing and matching thesemcard. Depending on the particular service, this price may be passedon to users by requiring cash payments, or it may be absorbed orsubsidized by the provider or advertisers, etc.

If users cannot find a semcard template that suits their needs fordescribing what they want to represent, they can extend the templatesalready provided, or create new ones that inherit from the ontologydefining the current templates. They can subsequently submit suchextensions to local semcard-capable servers, or to a central semcardontology repository. Such central repositories keep track of the mostpopular forms for describing various things in the world with semcards.Such repositories can provide semcard management application users witha list of the most popular semcards for representing various concepts inthe world. The statistics are received by virtue of linking to othersuch servers, such servers keeping track of the number of peoplesubmitting various types of semcards. (Semcard similarity is computedusing a matching engine, as described above.) The consolidation featureenables the system (or the end-user) to take all the fields from all thevarious alternative templates for a node and rank them in terms of (a)the number of active postings in the system that use such a field, or(b) the number of active opposite postings (if the post is an offer,then the opposite postings are requests) that seek that field). Then thesystem creates a consolidated form containing all the most importantfields from all the best alternative forms for that node (e.g. JobOffer), but ranked in terms of popularity. Thus the first dozen or sofields are probably the most widely used by users of the system. Thisenables a user to fill out the consolidated form instead of just oneparticular form, choosing the most popular fields to fill out from amongall the fields being used in all alternative form templates for thenode, and this will give them maximal compatibility and reach. Onceusers have created new semcard templates, or extended the ontology, theycan share such extensions with each other using semcards representingsemcard templates and ontology branches or whole ontologies.

The marketplace system of the present invention makes matching moreefficient by enabling seekers and providers to cooperate in finding oneanother, under a unified framework that fits into the semcard managementapplication and the semcard framework (but can also be implementedseparately through alternative solutions). By sharing the work, bothparties (and the computers of both parties) can share the workload forthe necessary transactions, making interactions more balanced. Thisfundamental process can improve a variety of processes, including:

Team & enterprise portals Search

Classified advertising Permission-based direct marketing

Personalized content distribution

Personalized commerce and shopping

Online marketplaces

Industry exchanges

Knowledge management Procurement

Supply-chain integration

Customer relationship management (CRM)

Communities-of-interest

Communities-of-practice

In the context of marketplaces, there are several features that make themarketplace more powerful, as will now be described. These features mayalso be used in other circumstances besides marketplaces.

The semcard management application provides a mechanism for rating thequality and reputation of content in the semcard management applicationnetwork and any knowledge network. Every semcard, Relationship semcard,as well as every group relationship, community relationship, and personasemcards, may have ratings associated with it. This enablescollaborative filtering, networks of trust, and reputation filtering totake place on the network.

Any semcard management application can have one or more accounts, eachone owned by a particular individual or group; each account can haveseveral “personas”—templates that dictate the terms of relationshipsthat its user has with others. The user of an account with multiplepersonas can be given a rating that is a function of the ratings of allits personas as given to it by those with whom he has relationships, orthe cumulated ratings given by others of all its posted semcards. Sincethe ratings of person A by person B is owned by person B, person A hasno control over the rating. The same holds for ratings of semcards: Arating by person A of semcard C, where semcard C is owned by person A,is not modifiable by person A. Since all semcards have a unique ID, andall users are represented by persona semcards, this creates a systemwhere communities of users can use ratings to control rogue individualsin the network.

A further extension of the utility of this mechanism is provided where aperson is represented by their account, allowing the cumulated ratingsof their Persona semcards to be reflected back on the account itself,and thus their actual identity, providing a community a furthermechanism to suppress unwanted behavior on the network.

A posting receives a starting rating that is a function of the rating ofits Persona designated as the semcard's author. Any rating given isaffected by the rating of the rater—this way people with higher ratinghave a larger say than people with lower/worse ratings on the network.The longer an account has been active on the network the more a newpersona created by the account owner will inherit the account's ratingfrom the start. This will benefit those that have an account with a highrating and discourage those whose account has a low rating.

A user can rate any semcard and relationship along several dimensions.This includes:

-   -   Match quality—was the match a good one? Is the matched semcard        useful for what it sets out to do?    -   Usefulness—how sensible is the match in the user's given        context?Appropriateness of language    -   Quality of matched semcard—how well/appropriately was it        specified?    -   Endorsements, with annotation

A semcard/ontology designer can also add custom rating fields to amatching pair of semcard types. A taxonomy of standard rating scales inthe system would be provided, however, users and communities can createtheir own additional custom ratings.

These ratings enter into the overall rating of a matched pair ofsemcards, as well as its posting party, and the account (persona) of theposting party. When viewing or interacting with a semcard, parties andusers can take these ratings into account.

Parties can also rate their experience with other users, including howsatisfied they are with follow-up, if the matched parties havecorresponded. Typically users will fill this in if they are notsatisfied or have a complaint.

Each party that rates can add a free-text comment. Their ratings for thepost, as well as their current persona ratings and statistics abouttheir general rating pattern, are summarized at the header of theircomment. The receiving party is allowed to reply and they can debate ina thread if they wish. This provides some checks and balances toratings. There is a policy for acceptable conduct in comments. If thatpolicy is violated, such as use of profane language, comments will bedeleted and the violator will be penalized on their persona ratings.

Forwarding is a function of the semcard management application, where anowner posts a semcard to another user that he himself received fromsomeone else. In direct manual forwarding semcard is forwarded manually,with no new policies. Semcards can be forwarded from one recipient toanother, either directly or indirectly, as described below in addressingmethods, as well as manually or automatically. Automatic forwardingmeans that the account has forwarding rules that posts particularsemcards to other recipients; manual forwarding means this is donemanually for each semcard.

When a semcard is forwarded it is wrapped in a second semcard whichcontains additional information, such as who forwarded, their rating,reasons for forwarding, rules (if forwarded by rules), etc. Theforwarding party may mask some original links and references withintermediate links and references, only to be traced back via theforwarding party, potentially being subject to policies set by theforwarding party.

Another mechanism is semcard brokering. In the case of brokered semcardsthe originator of a semcard is not visible to the ultimate receivingparty with whom there is a match; the brokering party acts as amiddleman for interactions resulting from a match between two semcards.To take an example, when two users receive a notification that theirsemcards matched, they cannot reply directly to each other, rather, theyreply to the brokering party, who in turn relays their replies to eachother.

The broker can set policies that restrict ensuing activity. For example,she may opt to be cc'd on all subsequent communications between thebrokered parties, and she may opt to have all communications between theparties go through her, with or without moderation. She can alsorestrict the types of matching that can occur, and the types offollow-up that are allowed.

In brokered situations, semcards inherit the rating of the brokeringpost. This way, semcards inherit any ratings from bad brokers, whichallows agencies to create filters that block semcards and/or agencieswith bad ratings. semcard brokering has features to manageaccountability, trace referral history, and transfer funds related tothe referrals and resulting matches.

Brokering differs from forwarding in that forwarding cuts the forwardingparty out of any subsequent transactions related to that semcard;brokering obligates the receiver to follow policies that the forwardingparty sets on the forwarded semcard. Also, in brokering mode, the brokermay benefit from any payment policies in the semcard. Semcard brokering,in contrast to forwarding, has features to manage accountability, tracereferral history, and transfer funds related to the referrals andresulting matches.

For example, a user may see or receive a job offer and wish to refer itto a friend who is looking for work. The receiving party may do whateverthey want with the semcard: match it, respond to it, delete it, andstore it.

There are several ways to advertise in a network of semcard managementapplications. The simplest way is to fill out an Offer semcard of type“advertisement” and post it to anyone who wants to get it that matchesthe targeting and policies of the advertisement. Another way is to embedor attach an ad semcard to another semcard, so that the ad semcardalways travels with it. However, the semcard management applicationprovides two other, ways of advertising using the idea of an “adstream”.

An ad stream provider can publish a semcard of type “Advertising StreamOffer” to content providers who subscribe to the ad stream. The adstream semcard contains meta-data about the content of the ad stream,i.e., the type of ad, the intended audience, how long the stream willrun and/or how many ads and impressions per ad are allocated to it, andwhat will be paid for each impression and each click to parties who runthe stream.

Content providers can subscribe for appropriate potential ad streams torun in their sites. Content providers who match may then reply to the adstream publisher with an application to receive the ad stream. Thepublisher can reply to the content providers with a custom URL for themto run on their ad slot of their Web site. The URL includes an encryptedID for the stream and an ID for the content provider. The contentprovider then runs the URL in its site's ad slots.

Visitors to the content provider's sites cause an ad to be pulled fromthat URL (which refers to the ad stream provider's ad server). Their adserver sees the ID of the semcard the ad stream came from and the ID ofthe site that pulled it and awards points to that site's account via thesemcard management application to compensate them for running the adstream. Subscriptions to certain types of semcards also createsubscriptions to certain classes of ad streams. In other words, thetargeting that is used to define a subscription is valuable for alsotargeting relevant ads to that subscriber.

For instance, a subscriber has a subscription to get offers for sportscars. When they make the subscription, it also automatically makes asubscription for ad streams that are targeted to people interested insports cars.

Certain classes of offers and requests contain slots for running ads inthe content of the envelope when it is displayed to the user. (In otherwords, they contain a slot for a URL that pulls from an ad stream.) Totake a specific example, when envelopes with sports car offers arematched to the sports car subscription for that account, advertisementsare automatically added to them depending on how they are being viewed:

1) If the sports car offer semcard is being viewed as HTML, an ad streamURL is inserted into the ad slot in the content. This causes theappropriate ad to be pulled from the ad stream provider and run in thecontent.

2) If the sports car offer semcard is being sent out to a fax machine,or to SMS, etc., the system either puts a TIFF image of the ad into theTIFF being faxed out, or it puts a text version of the ad into the SMSmessage, etc.

Thus, the particular ad and the format of the ad are not decided untilthe ad is received and/or displayed by a subscriber.

Furthermore, it is also possible to run ads on email and other types ofmessages. These ads subsidize the price of sending the messages. Ifusers do not want ads on their messages, they can spend points to buythe ad space.

Ad-free viewing can be paid up-front by the sender of a message or bythe receiving party (if either one pays for no ads, the other does nothave to pay, even though their settings are set up to filter out ads.)

Users of the semcard network can also buy ad space, either from a localnode owner (or from the owner of a central node in the network) and runtheir own ads in it. To profit they have to charge their advertisersmore than they paid for the ad space, creating a marketplace for adspace. So, for example, an advertiser buys the ad space on a messagesemcard that he is sending out to 100 people who are interested inmotorcycles. He pays ten cents up front for the ad space on thosemessages. He resells the ad space to a third party for($0.003/impression) grossing him 30 cents, and thus a net profit of 20cents.

The semcards' unique ID allows the system to track each semcard as ittravels on the network. Network nodes or semcard management applicationscan thus be automatically mined for top trends, topics, articles,resources, etc., which can also be encapsulated as knowledge in semcardand published back to users or central service.

The semcard management application provides an API for useful real-timeinformation about semcard activity in the network. All calculations arebased on raw data from the system events:

-   -   1. Posting a semcard    -   2. Receiving a semcard    -   3. Storing a semcard    -   4. Matching semcards    -   5. Splitting a semcard    -   6. Combining a semcard    -   7. Transmitting (routing) a semcard    -   8. Delaying the transmission of a semcard    -   9. Delaying transmission of parts of a semcard    -   10. Reliability of nodes    -   11. Efficiency of nodes    -   12. Displaying a semcard (e.g. browsable, or visible)    -   13. Ratings of a semcard or user account

In addition, statistics about the following (and more) can be recorded:

-   -   1. the type of semcards received and posted    -   2. semcards encapsulated in routing tables    -   3. semcards' slots (their number and types)    -   4. amount of content per slot (in bytes)    -   5. semcard owners (information stored in the semcard)    -   6. receivers (users who have been notified of matches)

The system can also provide statistics on higher-level phenomena likesupply and demand trends for particular types of offers, requests andsemcards, number of users with a particular interest profiles, number ofpotential matches for particular advertisements, and distribution of theuser population along multiple dimensions. One method to achieve thislast-mentioned option is to create a semcard describing the prototypicalcondition (average) for a particular trait. The marketing tool wouldgenerate multiple variations on this semcard using knowledge-based,iterative test-posts. The resulting semcard population would thenprovide actual statistics through multiple (hundreds, possiblythousands) of resulting matches, whose distribution describes the“semcard landscape” about the subset of the network that the semcardswould be targeted to when posted.

Standard information calculated includes aggregated statistics for allof these, e.g. total number of network matches for a given duration,where they occurred, as well as time-dynamics, demographicdistributions, popularity ratings, response rates, etc.

In addition to bar charts, pie charts, tables and graphs, the semcardsystem provides users options to visualize the path and dynamics of auser's semcard plotting their path in concept space, demographic space,or geographic space, and ranking their popularity compared to othersemcards in the network. This ranking assists other users in discoveringparticularly relevant semcards and helps those semcards reach largeraudiences. Statistics for the whole network, any node, or sets thereof,can also be viewed in the system, depending on the node's accessprivileges. Statistics for many of the accounts, agencies and persons onthe network can be browsed and searched via the semcard system. This isuseful for community accounts, which may advertise their membershippolicies, member statistics and other information about their existencevia semcards that can be browsed. It is also an important source ofinformation for companies, enabling them to visualize what the employeesare doing on their computers at the task and event-level—both providinga highly detailed resolution and high level of accuracy about what isactually happening. The high resolution of events and task recordingafforded by the semcards enables one to see an accurate depiction of awhole organization at a glance, and then to “zoom in” to areas ofinterest, to the level of a division, a team, and all the way down tothe level of an individual. This can be done both in time as well as ina large number of semantic dimensions.

The following is an example of how the present invention may be used.

-   -   1. Sue opens her semcard peer node application and logs in to        her business account.    -   2. Sue opens a word processor and creates a text document        called, “Marketing Plan”.    -   3. Sue creates a semcard for the “Marketing Plan” document. She        profiles it so that it can be seen by Phil, Lisa, and Dave, as        well as by anyone in the “Marketing Team” group. Sue sets the        semcard to include a copy of the “Marketing Plan” document        rather than just a link to it.    -   4. Sue does some market research on the Web and finds two useful        Web sites: “Industry Stats Central,” and “Industry Report”. The        system automatically creates a Web Site semcard for each one.    -   5. Sue browses her local semcard space for “biotechnology market        research” semcards. The results are 60 matching semcards.    -   6. Sue selects semcards for two more documents, “Biotech        Industry Report,” and “Biotech Industry Market Projections,”        from the search results and uses these semcards to create a new        Collection semcard called, “Biotech Market Research” that        includes them both. She then links the semcards “Industry Stats        Central” and “Industry Report” to it as well.    -   7. The semcards in a collection inherit a link to that        Collection, so from any semcard, Sue can see what, if any,        Collections it is in and navigate to those collections to see        what other items are related to it and then navigate to them.    -   8. Sue creates a Topic semcard called “Market Research” and        links this Topic semcard to other existing Topic semcards for        “Marketing,” “Advertising, “Strategy,” “Research,” “Project X,”        and “Product Development.” Each of these Topics now has a link        to the “Market Research” Topic semcard as well. Sue can navigate        around the resulting semcard map in various ways, by browsing,        filtering, querying, and visualizing    -   9. Sue adds the “Market Research” Topic semcard to the “Biotech        Market Research” Collection semcard. All of the semcards in the        collection are now linked to this Topic. The Topic also is        linked to the items in this collection. Now from the Market        Research Topic semcard Sue can find related documents and        topics, and vice-versa.    -   10. Sue creates a Collection semcard called “Biotech Marketing        Resources” and includes the semcards for “Marketing Plan,”        “Biotech Market Research” Collection semcard.    -   11. Sue searches for Web Sites related to Biotech Market        Research and finds “Industry Stats Central” and “Industry        Report.” She can see their metadata including their relations to        other Semcards. She can navigate around her knowledge this way.    -   12. Sue wants to send the “Biotech Marketing Resources” semcard        to her teammate, Phil. Sue uses the “Sharing” command on her        client to allow Phil to access it.    -   13. Phil gets is notified, in his semcard peer application or in        his email, that he has access to a new semcard from Sue called        “Biotech Marketing Resources.” Phil now has access to all the        semcards that are    -   14. linked to from that semcard, including any files that its        semcards included.    -   15. Phil now searches his knowledge store for “Biotech Market        Data” and finds 25 semcards. He links these 25 semcards to        “Biotech Marketing Resources.”    -   16. Phil shares his new links to the Biotech Marketing Resources        semcard with Sue. He attaches also a note explaining what these        new semcards are about.    -   17. Sue sees in her client that Phil has made links to her        semcard and shared the with her.    -   18. Sue now shares her “Biotech Marketing Resources” semcard to        anyone in the company who requests such resources, including        Phil's newly linked semcards. The semcard is routed to the        company's semcard server node, where it resides and is        automatically queried and delivered to anyone in the company.    -   19. Sue now makes a Request semcard for “Market Research        Consulting Services.” She fills out the Service semcard, and        posts it to selected departments within in the company. The        Request semcard is routed to the corporate semcard server node.        Sue receives matches to it as Offer semcards. She can then        correspond with the matched parties, negotiate, share further        semcards, schedule meetings or live web conferences, and hire a        consultant etc.

Although the foregoing invention has been described in some detail forpurposes of clarity of understanding, it will be apparent that certainchanges and modifications may be practiced within the scope of theappended claims. Furthermore, it should be noted that there arealternative ways of implementing both the process and apparatus of thepresent invention. For example, an application that doesn't useontologies to define concepts can nonetheless implement most of thefeatures described in this disclosure. Applications focusing onparticular vertical domains and markets, such as medicine, crimefighting, law, research, design, etc., can be built with specializedsemcards, using subsets of features described here or obvious butdomain-specific extensions to these. Furthermore, the semcard managementapplication as described can be adopted to handle othersemantically-rich entities besides semcards and others of those listedhere. Accordingly, the present embodiments are to be considered asillustrative and not restrictive, and the invention is not to be limitedto the details given herein, but may be modified within the scope andequivalents of the appended claims.

1. A method for creating a semantic object to represent a targetreferent of an object type, the semantic object being stored on acomputer readable medium, the method, comprising, creating a semanticobject of a semantic object type to represent the target referent of theobject type, the semantic object having multiple meta-tags that are eachassociable with metadata; wherein, the semantic object of the semanticobject type is suitable to represent the object type of the targetreferent; associating a meta-tag of the multiple meta-tags with themetadata; wherein the meta-tag or the metadata is definable using anontology; extracting a portion of the content from the target referentfor inclusion in the semantic object; and subsequently determining thatthe target referent has been revised, updating metadata associated withone or more meta-tags of the multiple meta-tags of the semantic objectbased on the revision.
 2. A method for creating a semantic object torepresent a target referent of an object type, the semantic object beingstored on a computer readable medium, the method, comprising, creating asemantic object of a semantic object type to represent the targetreferent of the object type, the semantic object having multiplemeta-tags that are each associable with metadata; wherein, the semanticobject of the semantic object type is suitable to represent the objecttype of the target referent; associating a meta-tag of the multiplemeta-tags with the metadata; wherein the meta-tag or the metadata isdefinable using an ontology; and extracting a portion of the contentfrom the target referent for inclusion in the semantic object; whereinthe extraction is part of a data mining performed on selected resourcesincluding the ontology or the Internet.
 3. The method of claim 2,further comprising, subsequently determining that the target referenthas been revised, updating metadata associated with one or moremeta-tags of the multiple meta-tags of the semantic object based on therevision.
 4. The method of claim 3, further comprising, sharing thesemantic object with another user and updating the metadata associatedwith the one or more meta-tags of the multiple meta-tags of the semanticobject to reflect a change made by the another user.
 5. The method ofclaim 3, wherein, the metadata is updated based on a revision of thetarget referent performed via a web browser.
 6. The method of claim 2,further comprising: maintaining a table of mappings between a pluralityof semantic objects and a respective set of target referents; andfurther providing a daemon that watches for changes and updates theassociation table accordingly.
 7. The method of claim 2, furthercomprising: maintaining a pointer from the semantic objects such thatthe pointer contains an address of a location of the target referent;and updating the address in the pointer if one or more of the semanticobject and the target referent are moved.
 8. The method of claim 2,wherein, the semantic object or the metadata is encrypted or digitallysigned.
 9. The method of claim 2, wherein, the semantic object is linkedto the target referent via a link semantic object.
 10. The method ofclaim 2, wherein, the semantic object is assigned a time to live afterwhich the semantic object expires.
 11. The method of claim 2, wherein,the metadata comprises an identity section including an owner or anauthor of the semantic object.
 12. The method of claim 11, wherein, theidentity section includes a recipient, a group, or a list of users ofthe semantic object.
 13. The method of claim 11, wherein, the identitysection includes one or more of, parties who have rated the semanticobject, parties that have been matched to the semantic object, andparties who have annotated the semantic object.
 14. The method of claim2, wherein, the target referent is a digital object comprising streamingmedia or other multimedia content.
 15. The method of claim 2, wherein,the target referent is a digital object comprising, one or more of,email, instant messages, and multimedia content.
 16. The method of claim2, wherein, the target referent is a digital object comprising anadvertisement.
 17. The method of claim 2, wherein, the target referentis a digital object comprising a web site or web page.
 18. The method ofclaim 2, wherein, the semantic object is able to represent an intangibleentity comprising an idea or a concept.
 19. The method of claim 2,wherein, the semantic object is stored on the computer readable mediumas an XML object using RDF or another binary storage format.
 20. Themethod of claim 2, further comprising, creating the semantic object inresponse to receiving a user request or an event-based trigger.
 21. Themethod of claim 20, wherein, the event-based trigger is detected fromone or more of, a file directory and an application.
 22. The method ofclaim 2, further comprising, creating the semantic object in responseto, receiving an automatic trigger.
 23. The method of claim 22, wherein,the automatic trigger is generated responsive to data-mining a knowledgeresource.
 24. The method of claim 3, wherein at least one of thecreating of the semantic object and updating of the semantic object istriggered by one or more of the following events, comprising: saving adocument or data item; creating a document or data item; opening orviewing a document or data item; modifying a document or data item;transmitting a document or data item; receiving a document or data item;deleting a document or data item; and integrating documents or dataitems with existing file servers, databases or search engines.
 25. Themethod of claim 2, further comprising, embedding the semantic object inthe target referent.
 26. The method of claim 2, wherein the semanticobject is created in a process of matching offers and requests, an offerrepresented by an offer object and a request represented by a requestobject, and wherein the offer object and the request object are semanticobjects that include metadata defining particulars of the offer and therequest.
 27. The method of claim 26, wherein, wherein the offer objectand the request object are created via a user interface on a computersystem.
 28. The method of claim 26, further comprising, determiningwhether there is a match between the offer object and the request objectby comparing an offer object meta-tag and a request object meta-tagand/or by comparing an offer object metadata and a request objectmetadata.
 29. The method of claim 26, further comprising, computing asimilarity measure between the offer object and the request object basedon the comparison between the offer object metadata and the requestobject metadata or the comparison between the offer object meta-tag andthe request object meta-tag.
 30. The method of claim 26, wherein theoffer object or the request object is presented to an explicitly namedrecipient or to a selected recipient that satisfies a criteria.
 31. Themethod of claim 30, wherein the selected recipient is identified basedon a fuzzy definition or using a matching engine.
 32. The method ofclaim 31, wherein, the metadata is maintained by storing offer orrequest metadata in meta-tags in the semantic object.
 33. The method ofclaim 31, wherein, the metadata is maintained by creating a separatesemantic object and storing the offer or request metadata in theseparate semantic object, and wrapping the semantic object using theseparate semantic object.
 34. The method of claim 31, wherein, themetadata is maintained by creating a separate semantic object andstoring the offer or request metadata in the separate semantic object,and creating a reference pointer between the semantic object and theseparate semantic object.
 35. The method of claim 2, further comprising,test posting the semantic object to provide an estimate of a number ofmatches; and providing for revision of the semantic object based on thetest posting.
 36. The method of claim 2, wherein, the multiple meta-tagscomprises, a customized set of meta-tags that are user-definable; andwherein the metadata is user-specifiable or machine-specifiable.
 37. Themethod of claim 2, further comprising, automatically identifyingmetadata of the target referent to be associated with the metadata ofthe semantic object representing the target referent.
 38. The method ofclaim 2, further comprising, exchanging information about the ontologyusing the semantic object.
 39. The method of claim 2, wherein, thesemantic object has a set of rules, comprising, a display rule of thesemantic object.
 40. The method of claim 39, wherein, the display ruleis determined based on a display device, a particular render, and/or apurpose for viewing the semantic object.
 41. The method of claim 39,wherein, the set of rules further comprises, an access rule of thesemantic object.
 42. The method of claim 41, wherein, the access rulespecifies whether the semantic object can be modified by another userand whether the modification is subject to approval of the owner. 43.The method of claim 41, wherein, the access rule specifies a linkingrule that governs whether the semantic object can be linked to by othersemantic objects.
 44. The method of claim 29, wherein, the set of rulesfurther comprises, one or more of, an automation policy, a modificationrule, and an update rule of the semantic object.
 45. A method forcreating a semantic object to represent a target referent of an objecttype, the semantic object being stored on a computer readable medium,the method, comprising, creating a semantic object of a semantic objecttype to represent the target referent of the object type, the semanticobject having multiple meta-tags that are associable with metadata;wherein, the semantic object of the semantic object type is suitable torepresent the object type of the target referent; associating a meta-tagof the multiple meta-tags with the metadata; wherein the meta-tag or themetadata is definable using an ontology; and exchanging informationabout the ontology using the semantic object.
 46. The method of claim45, further comprising, extracting a portion of the content from thetarget referent for inclusion in the semantic object; and wherein theextraction is part of a data mining performed on selected resourcesincluding the ontology or the Internet.
 47. The method of claim 45,wherein, the semantic object is transmittable over a computer networkvia one or more of, email and Web protocols.
 48. The method of claim 45,wherein, the semantic object is transmittable over a computer networkvia a peer-to-peer protocol.
 49. The method of claim 45, furthercomprising, embedding the semantic object in the target referent.
 50. Amethod for creating a semantic object to represent a target referent ofan object type, the semantic object being stored on a computer readablemedium, the method, comprising, creating a semantic object of a semanticobject type to represent the target referent of the object type, thesemantic object having multiple meta-tags that are associable withmetadata; wherein, the semantic object of the semantic object type issuitable to represent the object type of the target referent;associating a meta-tag of the multiple meta-tags with the metadata;wherein the meta-tag or the metadata is definable using an ontology;assigning one of multiple lifecycle stages to the semantic object; andsubsequently transitioning the semantic object from one of the multiplelifecycle stages to another; wherein, the semantic object has anassociated display rule.
 51. The method of claim 50, wherein, thedisplay rule is determined based on a display device, a particularrender, and/or a purpose for viewing the semantic object.
 52. The methodof claim 50, further comprising, exchanging information about theontology using the semantic object.
 53. The method of claim 50, wherein,the multiple lifecycle stages include at least one of: a draft stage, anactive stage, an inactive stage and a deleted stage.
 54. The method ofclaim 50, wherein, the transitioning is driven a time-to-live of thesemantic object after which the semantic object is deleted orinactivated.
 55. The method of claim 50, wherein, the transitioning isdriven by user-driven events and/or automatic rules.